Re: [osg-users] Raytracing status

[Aashish Chaudhary]

Adrian,

Though I am not an expert on ray tracer.in fact know only the basics.. but I
am more than happy to help you out with this.. you can send me emails at
[EMAIL PROTECTED]


On Dec 13, 2007 12:36 AM, Adrian Egli <[EMAIL PROTECTED]> wrote:

> Hi all,
>
> what i still mentioned in the past is that i 'd like to replace the
> linear search (O(n)) for triangle intersection test by a faster O(log(n))
>
> (LineIntersection / Intersection Visitor). A line intersection is similar
> to a ray
> intersection, so we are really close to ray tracing. With the www.ompf.organd
> their know how, it sould be possible to get really soon a close to real
> time ray tracer.
> there exist a open source (GPL) real time ray tracing project called
> arauna ( rt07.raytracing.nl
>   or http://www.gamedev.net/community/forums/topic.asp?topic_id=463595 ).
> once we have speed up the intersection visitor we can go further. still
> volume rendering / ray casting could be
> introduce once with similar ideas. (
> http://www.cg.tuwien.ac.at/courses/MedVis2/MedVis2.html)
>
> what i am looking for is, a community helping implementing such  tuning
> algorithm. who like to introduce this
> into osg, or who like helping me in implementing. there is still 
> jean-sebastien,
> others ?
>
> /adegli
>
>
>
> 2007/12/13, Jean-Sébastien Guay < [EMAIL PROTECTED]>:
>
> > Bonsoir Charles,
> >
> > > would the design of your current raytracer code lend itself to tracing
> > > voxels filled with smoke or water?
> >
> > Adrian would be the best placed to answer, as he wrote it, I only used
> > it. But from what I saw it only currently supports ray-triangle
> > intersection, nothing is done about participating media.
> > Reflection/refraction for the surface of water would be pretty easy,
> > but smoke or ripples on the surface of water (or any other fluid) is
> > another thing. ("une autre paire de manches!")
> >
> > Once we get a good basic raytracer going, it will be possible to
> > integrate effects into it fairly quickly. That's the great thing about
> > raytracing in general, it's a very intuitive technique. (but I think
> > I've said that before in a previous thread, not so long ago... :-)
> >
> > J-S
> > --
> > __
> > Jean-Sebastien Guay [EMAIL PROTECTED]
> >  http://whitestar02.webhop.org/
> >
> > 
> > This message was sent using IMP, the Internet Messaging Program.
> >
> >
> > ___
> > 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mouse Picking (again...)

[Andreas Goebel]

>
> I was going to attach the souce code to this message, but I've given 
> up, for I know that what I really need is an understanding of the 
> basics of mouse picking. but I mean the true and real basics. What 
> I mean with basics? I need to understand every line of that 
> pickhandler class for starters If not, at least an understanding 
> on how to USE this class...
>
> Anyone's been through a similar situation and/or might be able to help me?
>
> Thank you
>
> Renan M Z Mendes
Hi,

I have been through exactly that, as I wrote a software for spatial 
geometry. See here: www.raumgeometrie.de

I can assure you that the new pick-classes work perfectly well with 
shape Drawables, all my code is based on that. There must be a simple 
mistake on your side.

But you might want to have a look at my software before reinventing the 
wheel.

The basic function is:

- your mouse is in screen-coordinates
- the screen-coords wil have to be transformed back to world-coordinates 
(which is done automatically by a convenience function of the intersector)
- you will have to make something three-dimensional of the 
two-dimensional screen-coordinates, usually using the near and far 
clip-planes (automatically done by the intersector)
- now you have a segment that lies exactly behind your mouse-pointer
- the segment is intersected with the node that is passed to it
- (this is done roughly like this: Intersection tests are made for the 
bounding volumes of each node, if it intersects, one goes further down 
the tree until real geometry is met. Here intersection is calculated 
against all triangles)

I use a LineSegmentINtersector, which works just perfectly for picking.


Regards,

Andreas



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Development-system for Mac-OS

[Andreas Goebel]

E. Wing schrieb:
> In my opinion, you are best off getting Leopard. Apple will not be
> updating OpenGL drivers for Tiger from this point on. Working OpenGL
> drivers is by far the most important aspect in my opinion.
>   
Thank you all,

I summarize: I´d (probably) be best of with:
- Mac OS 10.5
- but use 10.4 sdk to target both 10.4 and 10.5

right?

I know that the slogan is "think different", so that´s what I´ll have to 
do ...


Regards,

Andreas

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Raytracing status

[Adrian Egli]

Hi all,

what i still mentioned in the past is that i 'd like to replace the
linear search (O(n)) for triangle intersection test by a faster O(log(n))
(LineIntersection / Intersection Visitor). A line intersection is similar to
a ray
intersection, so we are really close to ray tracing. With the www.ompf.organd
their know how, it sould be possible to get really soon a close to real time
ray tracer.
there exist a open source (GPL) real time ray tracing project called arauna
(rt07.raytracing.nl
  or http://www.gamedev.net/community/forums/topic.asp?topic_id=463595 ).
once we have speed up the intersection visitor we can go further. still
volume rendering / ray casting could be
introduce once with similar ideas. (
http://www.cg.tuwien.ac.at/courses/MedVis2/MedVis2.html)

what i am looking for is, a community helping implementing such  tuning
algorithm. who like to introduce this
into osg, or who like helping me in implementing. there is still
jean-sebastien,
others ?

/adegli



2007/12/13, Jean-Sébastien Guay <[EMAIL PROTECTED]>:
>
> Bonsoir Charles,
>
> > would the design of your current raytracer code lend itself to tracing
> > voxels filled with smoke or water?
>
> Adrian would be the best placed to answer, as he wrote it, I only used
> it. But from what I saw it only currently supports ray-triangle
> intersection, nothing is done about participating media.
> Reflection/refraction for the surface of water would be pretty easy,
> but smoke or ripples on the surface of water (or any other fluid) is
> another thing. ("une autre paire de manches!")
>
> Once we get a good basic raytracer going, it will be possible to
> integrate effects into it fairly quickly. That's the great thing about
> raytracing in general, it's a very intuitive technique. (but I think
> I've said that before in a previous thread, not so long ago... :-)
>
> J-S
> --
> __
> Jean-Sebastien Guay [EMAIL PROTECTED]
>  http://whitestar02.webhop.org/
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
> ___
> 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] readFontFile possible bug

[sherman wilcox]

I spent a bit of time this evening digging up the the code that
reproduces the crash. I'll update to the SVN snapshot of OSG and give
it a try. I was able to reproduce the crash on 2.2.0.

On Dec 12, 2007 4:22 AM, Robert Osfield <[EMAIL PROTECTED]> wrote:
> Hi Sherman,
>
> On Dec 11, 2007 11:31 PM, sherman wilcox <[EMAIL PROTECTED]> wrote:
> > I can still reliably reproduce the multithreaded osgText /
> > databasepager crash issue   :)
>
> Could you explain how your recreate the crash, and the circumstances
> of the crash.  It may be exactly the same problem as Serge has, but
> also just as easily could be another weakness that needs solving.
>
> Aaa you gotta love debugging multi-threaded apps remotely :-)
>
> Robert.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mouse Picking (again...)

[Renan Mendes]

Hi, there, people.

It's been a bunch of days that I've been trying to learn how to deal with
mouse picking and stuff. I found a pickhandler class on Paul's book and
tried to implement it simply by copying and pasting it to my source code
(yeah, I'm really new at the whole osg universe, and even computer graphics
for that matter). Well, it didn't work. I came to the people on this mailing
list and asked them. What was then said to me was that it didn't work
because I was using ShapeDrawables and that the Pickhandler class was not
designed to deal with them - I needed osg::geometry-based spheres, boxes and
cylinders for it to work.

Here I am, then, asking anyone that can answer me, why it didn't work even
though I used a box rendered vertex by vertex?

Basically, my application is consisted of three classes representing the
geometric primitives: plane, point and line. Because I want to represent
them well (it is a software to help in the teaching of spatial geometry) I
didn't use the correlated primitives osg already offers. Instead, I used
(thin) boxes, (small) spheres and (thin) cylinders. My user is supposed to
select each one of these shapes and do stuff with it. But before I create
the stuff, I need them to be able to select the shapes, i.e., pick them
using the mouse.

I was going to attach the souce code to this message, but I've given up, for
I know that what I really need is an understanding of the basics of mouse
picking. but I mean the true and real basics. What I mean with basics? I
need to understand every line of that pickhandler class for starters If
not, at least an understanding on how to USE this class...

Anyone's been through a similar situation and/or might be able to help me?

Thank you

Renan M Z Mendes
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Raytracing status

[Jean-Sébastien Guay]

Bonsoir Charles,

> would the design of your current raytracer code lend itself to tracing
> voxels filled with smoke or water?

Adrian would be the best placed to answer, as he wrote it, I only used  
it. But from what I saw it only currently supports ray-triangle  
intersection, nothing is done about participating media.  
Reflection/refraction for the surface of water would be pretty easy,  
but smoke or ripples on the surface of water (or any other fluid) is  
another thing. ("une autre paire de manches!")

Once we get a good basic raytracer going, it will be possible to  
integrate effects into it fairly quickly. That's the great thing about  
raytracing in general, it's a very intuitive technique. (but I think  
I've said that before in a previous thread, not so long ago... :-)

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG version

[Bob Kuehne]

i like this idea, paul. perhaps the version could be tagged something  
indicating 'development' between release tags, for example: '2.3.0- 
beta', and then once robert gets to his release point, changing to  
'2.3.0', tagging, and then immediately changing to '2.3.0-beta'. or  
maybe this immediately post-release version number is something like  
'2.3.1'.

ruminate...

bob


On Dec 12, 2007, at 5:00 PM, Paul Martz wrote:

>> I'll bump the version number up once I tag the 2.3.0 release,
>> I've been hanging back while more testing is carried out.
>
> Can I suggest a change in policy? The version number should get  
> bumped as
> soon as the first post-release change is committed. At that point,  
> the code
> no longer matches the previous release; the version number should  
> increment
> to reflect that.
>
> If the SVN head version number contains post-release changes but the  
> version
> number is unchanged, then code written for specific releases might  
> not run
> on the current SVN head, thus delaying testing.
>   -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

Re: [osg-users] Raytracing status

[Charles Cossé]

Hi Guys,
would the design of your current raytracer code lend itself to tracing
voxels filled with smoke or water?
Thanks,
-Charles

On Dec 12, 2007 8:50 AM, Jean-Sébastien Guay <[EMAIL PROTECTED]>
wrote:

> Hello Michele,
>
> > Thank you Jean, Adrian was kind enough to send me already its code, I
> > am reviewing it now :)
>
> Good, I don't have access to my home machine so I would have sent it
> to you in a few hours... :-)
>
> > I was thinking, maybe it wouldn't be a bad idea to integrate YafRay
> > into OSG, the license (LGPL) seems ok with it, unlike POV-Ray.
>
> When I started my Masters, my first attempt was to try and make an
> interface between OSG and Yafray. Unfortunately, the main developer
> (Lynx) was not very open to requests to changes in the build system
> and other things that would have made this kind of development easier.
> He seemed to just want to do his thing, not really wanting external
> programs to use Yafray code directly (but that may just be an
> impression - take it with a grain of salt).
>
> In the end, I just used OSG's IntersectionVisitor and eventually
> Adrian's kd-tree. I didn't really need advanced effects, just
> intersection testing, so that was enough. But if Lynx can be brought
> on to help do a real integration of Yafray with OSG with the goal of
> doing some realtime raytracing, that may be really interesting.
>
> If the question is which Open Source raytracer would be the best to
> try such an integration, Yafray is definitely my first choice. It's
> really fast, and gives very good results.
>
> J-S
> --
> __
> Jean-Sebastien Guay [EMAIL PROTECTED]
> http://whitestar02.webhop.org/
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
AsymptopiaSoftware | [EMAIL PROTECTED]
www.asymptopia.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Development-system for Mac-OS

[Bob Kuehne]

hi andreas,

you can get whatever mac you want, as the sdk and os are independent,  
to some extent. that is, you can be running 10.5, but build  
applications that target 10.4 or earlier. so, for osg, this means  
building your app against the 10.4 sdk (included as part of the  
development tools). i've been building and using osg and osg apps on  
10.5 for months now, without problems...

bob

On Dec 12, 2007, at 2:57 PM, Andreas Goebel wrote:

> Berg, Michael schrieb:
>> I don't think the problems weren't just 64-bit.  About a month ago  
>> (), I
>> posted a message with the subject "Undefined Symbols in OSG on Mac  
>> OS X"
>>
>> The OSG binary installer for Mac OS X 10.4 (the 10.4u SDK) *mostly*
>> worked, but my applications would not compile if I made calls to
>> osg::Image::readPixels() or osg::StateSet::setMode().
>>
>> E. Wing replied that:
>> =
>> Yeah, Apple screwed up and broke binary compatibility between 10.4  
>> and
>> 10.5 when using OpenGL and C++. I have notes and binaries coming on
>> this, but the short story is you can't use 10.4 built frameworks
>> against the 10.5 SDK or you get the linking problems you see. Either
>> switch to the 10.4u SDK on Leopard, or use a set of OSG frameworks
>> built against the 10.5 SDK.
>> =
>>
>> Anyway, once the Mac OS X 10.5 SDK (32-bit only) was released and I
>> upgraded to it (http://www.openscenegraph.org/projects/osg/wiki/Downloads 
>> )
>> it solved the linking problems I was having.
>>
>> If you look through the release notes for the 10.5 SDK, it mentions  
>> that
>> Apple changes some of the types in the OpenGL headers, so OSG had  
>> to be
>> rebuilt for that.
>>
> Hi,
>
> thanks for the info. But does that mean that I would avoid those
> problems by simply using Mac OS 10.4 ?
>
> 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] Development-system for Mac-OS

[E. Wing]

In my opinion, you are best off getting Leopard. Apple will not be
updating OpenGL drivers for Tiger from this point on. Working OpenGL
drivers is by far the most important aspect in my opinion.


I've already added a bunch of documentation to the OSGWiki.
On just Leopard issues:
http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5

However, don't misinterpret this as 'everything works fine on Tiger'.
For example, we talk about lack of 64-bit support on Leopard with the
current state of Mac/OSG code. We don't discuss it much on Tiger
because 64-bit OpenGL wasn't supported at all on the OS. Also, the
OSX/OSG Readme we ship with the binary packages attempt to document
all the major OS X specific problems we've come across.

-Eric



On 12/12/07, Andreas Goebel <[EMAIL PROTECTED]> wrote:
> Berg, Michael schrieb:
> > I don't think the problems weren't just 64-bit.  About a month ago (), I
> > posted a message with the subject "Undefined Symbols in OSG on Mac OS X"
> >
> > The OSG binary installer for Mac OS X 10.4 (the 10.4u SDK) *mostly*
> > worked, but my applications would not compile if I made calls to
> > osg::Image::readPixels() or osg::StateSet::setMode().
> >
> > E. Wing replied that:
> > =
> > Yeah, Apple screwed up and broke binary compatibility between 10.4 and
> > 10.5 when using OpenGL and C++. I have notes and binaries coming on
> > this, but the short story is you can't use 10.4 built frameworks
> > against the 10.5 SDK or you get the linking problems you see. Either
> > switch to the 10.4u SDK on Leopard, or use a set of OSG frameworks
> > built against the 10.5 SDK.
> > =
> >
> > Anyway, once the Mac OS X 10.5 SDK (32-bit only) was released and I
> > upgraded to it (http://www.openscenegraph.org/projects/osg/wiki/Downloads)
> > it solved the linking problems I was having.
> >
> > If you look through the release notes for the 10.5 SDK, it mentions that
> > Apple changes some of the types in the OpenGL headers, so OSG had to be
> > rebuilt for that.
> >
> Hi,
>
> thanks for the info. But does that mean that I would avoid those
> problems by simply using Mac OS 10.4 ?
>
> 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] INHERIT_RENDERBIN_DETAILS

[Paul Martz]

Hi -- Not sure what you mean by "priority". The render bin number specifies
relative drawing order of sibling Nodes and Drawables. If each of your
Geodes' Drawables must get drawn in a certain order, then you should set the
render bin number on the StateSet of each Geode's render bin; Drawables will
be rendered in ascending render bin number order.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Argentieri,
John-P63223
Sent: Wednesday, December 12, 2007 12:08 PM
To: OpenSceneGraph Users
Subject: [osg-users] INHERIT_RENDERBIN_DETAILS



Hello all. 

We are using inherit renderbin details to assign a nested set of priorities.
We have a group node with a top-level priority which contains several geodes
with priorities using the inherit flag. Each of the geodes has a textured
polygon geometry. We want to have the polygons depth test disabled and drawn
in a certain order so that they will show the last drawn on top.

OSG is not drawing these in order as it should. Any ideas what the problem
might be? We haven't used the override renderbin details flag anywhere, so
it is bizarre that things are happening this way. We can turn on blending
and lower the alphas and see that both our polygons are there.

John Argentieri 
Software Engineer 
GENERAL DYNAMICS 
C4 Systems 
(407) 281-5568 
[EMAIL PROTECTED] 

"This email message is for the sole use of the intended recipient(s) and may
contain GDC4S confidential or privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not an
intended recipient, please contact the sender by reply email and destroy all
copies of the original message."

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Looking towards 2.4, and what might go into it.

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Jeremy,

Jeremy Moles wrote:
> 
>> Nothing more was ever implied given the code provided, so I'm not sure
>> why you even brought this up? The example is clearly a purposefully
>> succinct and shortened summation. What "brings it up to speed" is adding
>> the mixing, interpolation, etc, which I also mentioned at the end of the
>> paragraph.

Yes, I agree, however, who is going to do it? Those parts are the least
"sexy" and most difficult in the animation code. My answer wasn't so
much targeted at you (you know what this stuff is about, I believe), as
much as at the others who could get a false impression that once we have
a skeleton support and skinning code, all is going to work by magic.

>> Secondly, and I'm not speaking as a total foreigner here since I do have
>> a lot of experience w/ Cal3D and a decent amount of affiliation with the
>> project, "when he can use osgCal or Replicant that work already" is
>> really the issue that is up for debate in my mind.

My issue is more on the resource level - is there anybody willing to
commit himself to redo this stuff that Cal3D provides? The animation
parts are tricky, requiring good math skills and certain experience. I
didn't see anybody stepping up and saying "I will do this" until now.
Unless we have this, it would be rather unwise to make a half-cooked
toolkit that is not practically usable.

>> Vladimir has made many posts regarding his changes to osgCal2 today, and
>> from the information I can gather he was required to basically
>> re-implement portions of Cal3D in his plugin just to get acceptable
>> performance and support for hardware skinning. It sounds like osgCal2 is
>> really more of a hybrid Cal3D adaptation than just a simple Cal3D
>> wrapper/plugin. While his changes my create the outward appearance of
>> animation "working already", as a developer it certainly doesn't qualify
>> as such to me, though I often admittedly fall victim to putting too much
>> emphasis on the wrong things.

I think that this was answered elsewhere by him already.

> 
>> Perhaps Cal3D just isn't the tool for the job here. Or at least, it
>> shouldn't (and perhaps I'm wrong for believing will become as much) be
>> THE character animation solution for OSG, long term.

I agree with this, however, there isn't anything better on the table at
the moment. Unless somebody offers to replace Cal, I suggest an
evolution rather than revolution. I gather that this is also what Robert
wants, judging from one of his last emails on the topic. If we can
eliminate the dependency on Cal long term, great. However, I would
hesitate to remove it until we have a replacement, including the design
pipeline.

>> At any rate, unless I'm willing to step up and code to solve the
>> problem, I probably shouldn't say too much more on the issue. Unless I'm
>> able to provide real working code, it just looks like I'm forum
>> trolling, which I'm not trying to do. :)

:-))

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFHYFzon11XseNj94gRAhPvAJ0YI+GqRuOuHwqxvLNaPR3lbwLQxACg1cd7
z/QGWZKaZ5KLoCTd+E5B4ac=
=Yeu4
-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] osgPhysics

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Paul,

Paul Martz wrote:
> I'm interested in working on / contributing to physics integration in OSG. I
> have funding from a client for some of this work. The primary focus will be
> enabling physical interaction of large, complex models, precomputing physics
> metadata for fast loads, allowing for varying levels of realism as a
> tradeoff against performance, etc. This is a long-term project (1-2 years).

That sounds great. It isn't exactly what I am doing ATM, but it could be
a good motivation for a high quality integration. I can try to factor
out the relevant code from our engine into a small example and send you
something, so we can discuss the design issues.

However, working with large models may be a problem - I do not know how
would the existing free physics engines cope with that. It could be a
problem requiring a very specific solution, not using a generic physics
engine. What type of models/data are we talking about?

Regards,

Jan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFHYF3jn11XseNj94gRAiYkAJ9mwRkoLvT25i+gxZlIiYU8HtEK9wCfTbNM
KItLzJXTSB2I4qV+CoLds6A=
=bPfd
-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] Looking towards 2.4, and what might go into it.

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vladimir Shabanov wrote:

> As I said before cal3d meshes are not used by osgCal for performance
> and memory usage reasons. They are used at export stage to generate
> ready to direct load meshes file. For compability loading from cal3d
> .cmf-files is still here.
> 
> The only things needed to be integrated in OSG to remove cal3d
> dependeny are skeleton support and skeleton animation support. OSG and
> osgCal have all other things.

Skeleton animation is actually probably the trickiest part. Getting
animations to blend right and to mix right, allowing procedural
animation (bones driven by an algorithm, not just keyframe
interpolation) and such are quite a big deal. That is why I am not so
enthusiastic about ripping out Cal3D - nobody has so far offered to do
this hard part. Rendering it is comparably easy.

> 
> But skeleton animations is not enough, exporters to these animations
> are also needed. It is artist pipeline that need most work.

Very important point!

> No. It's not linux only. osgCal2 works on windows also. There is no
> CMake files in osgCal2, it uses old OSG make files to make osgCal on
> unix systems and on mingw under windows. People have made Visual
> Studio project files and osgCal works ok on windows.

I didn't try the hardware accelerated version, but the software skinned
one used to work just fine on Windows, indeed.


Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFHYFjvn11XseNj94gRAliKAJ92I/sQvTRduNCzMOkCT6PlJ1yPmQCgxTXB
4oGghkNNzCmVB1QdsnRfVyI=
=GIwL
-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] OSG version

[Paul Martz]

> I'll bump the version number up once I tag the 2.3.0 release, 
> I've been hanging back while more testing is carried out.

Can I suggest a change in policy? The version number should get bumped as
soon as the first post-release change is committed. At that point, the code
no longer matches the previous release; the version number should increment
to reflect that.

If the SVN head version number contains post-release changes but the version
number is unchanged, then code written for specific releases might not run
on the current SVN head, thus delaying testing.
   -Paul

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Looking towards 2.4, and what might go into it.

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vladimir Shabanov wrote:

> Yes, it has different implementation. But what about skeletal
> character with morphing face and maybe some particles around his body
> (imagine a small devil). Different rendering methods are tightly
> coupled here. And their animations must be synchronized.
> 
> So while the rendering implementation can be separated (not sure about
> morphs and skeleton) the animations must be ran from single place.

You have a valid point here. However that doesn't require a huge,
all-encompassing node kit for managing all kinds of animation, does it?

If you want to have a character that is both skeletally animated and has
morph targets for e.g. face, it could be a composite structure with two
components - face and the rest. I would leave this to the user to
implement a class managing a character like that and have OSG have two
animation node kits - one for skeleton, deforming the mesh and then
another one that will work on the pre-deformed mesh and fix the face or
whatever. The morphing is useful even without the skeletal animation
that brings a lot of extra baggage in and I wouldn't like it to be
tightly tied together. However, this could be tricky to implement.

Otherwise, then let's not talk about a general animation package but
something specific to character animation. Then it would be OK to have a
character class supporting both things out of the box, but we wouldn't
be pretending that this is something more generic.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFHYFgYn11XseNj94gRArtvAJ0aexy7mtZZiR2O+vlJVDBNgcJ1VwCdERc9
wZ84pXuBajnwdJCi2a4Ce7Q=
=RYar
-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] Looking towards 2.4, and what might go into it.

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jason Daly wrote:

> osgCal/Replicant are great, provided that you want to use Cal3D 
> characters only.

Why? Where is a problem about taking a character/animation from Collada
and creating the Cal3D skeleton structure from it on loading? That is
what the Cal3D loaders do. Cal3D doesn't really expect anything exotic,
so it should be very easy to do. I didn't do it for mesh, but I had a
Cal3D character skeleton created and driven from "outside" before.
Nothing crazy was required.

The only exception are probably LOD levels in Cal that work in a bit
unusual way - by collapsing mesh dynamically - instead of the more
"normal" way of swapping around different meshes, but that is not really
an issue, especially if the software skinning in Cal is not used.

> I don't think the idea behind osgSkeleton is limited to a transformation 
> hierarchy.  Most OSG users know we already have that functionality.  My 
> understanding is that osgSkeleton would provide the necessary 
> infrastructure for skinning and character animation, and the required 
> data could come from Collada, Cal3D, or whatever other plugin that can 
> provide it.  

That is fine, but I do not see much point in it - it would be only
re-implementation of what already exists in Cal3D.

> That's the main advantage I see in creating a new nodekit.  It makes the 
> rendering orthogonal to the data format.

Is the current Cal3D situation different? Non-orthogonal? I understand
that you are somehow implying that without using the Cal3D data formats
you cannot use Cal3D library. That isn't the case, as outlined above.
Cal doesn't care where the data come from once they are loaded. If you
load them from Collada file, no problem.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFHYFXzn11XseNj94gRAui8AJ9EjTvrnrAyHp/APfoCVvOdJBOjOgCgz1Gl
I+MSnqL7/+eKRclYsvGBAKQ=
=gfRw
-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] Looking towards 2.4, and what might go into it.

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Halliday wrote:

> I've been using osgswig ( http://code.google.com/p/osgswig/ ) for a
> project on a cave-type system combining python, vrjuggler, and osg.
> osgswig supports python, ruby, java and lua, although I've only played
> with the python features. I had tried to use osgPython and pyosg before,
> but they only work with older versions of osg.

Interesting, I didn't know about this project! Thanks for the pointer!

>> / 2) Application is written in a high level language and calls into C/C++/
>> / code to run the performance critical stuff. I think that this is what/
>> / you want ("... enable us to/
>> / develop applications purely from scripting languages, so developers in/
>> / this realm would just need the binaries to the OSG installed, and no/
>> / need for C++ dev environment").
> 
> /The osgswig project seems to be primarily designed for scenario 2,
> although in my application I've been using osgswig as in scenario 1 by
> getting out a void pointer to the opaque values from the python api. I'm
> not sure how possible this approach is with other languages though.

It usually works in the same way if you are using SWIG - you get a void
pointer packaged into some opaque data structure (e.g. a SMOB for Guile)
and you are passing that around. However, if the bindings are made using
a different tool, this could be different.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFHYFQOn11XseNj94gRAppsAJ9FKDi2zX4EGao8ftGEdfatY2pM7ACeIOzm
rCZ1YXKvB0SzqoKqUM8LDL0=
=2jic
-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] Creator vs 3D Studo Max- Blender

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dunhour, Mike (CIV) wrote:
> 
> Hello 
> 
> Noticed in this discussion talk about Blender and .OSG
> 
> So just thought I'd mention these Blender Papers I did for the Delta 3D
> Team to be found here
> 
> http://www.delta3d.org/article.php?story=20051207101455773&topic=docs
> 
> located at the bottom of the page
> 
> they go over the basics of running Blender and how to edit a .osg file
> kicked out of Blender.
> 
> Might be of interest to some people out there

Cool, that is interesting.

However, you may want to add a part on fixing the absolute filename for
the texture in the examples ("file
C:\3d\Blender2.43\Blender\images\bllt_sng.tga") - that is a fairly
horrible thing to leave in, because such model will load right only on
designer's machine or somewhere where the OSG_FILE_PATH is set up.

We are putting the .osg file + textures using a relative path and
packing everything into a .zip file. In that way things stay together
and the model is easily transferable from one machine to another.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFHYFNGn11XseNj94gRAmgaAKDhPiHIWx1Vi6okBJF4Y1qCS1n5fACdEJlg
ATUQY61TCbbTEiankuPVdUs=
=xbDa
-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] Development-system for Mac-OS

[Andreas Goebel]

Berg, Michael schrieb:
> I don't think the problems weren't just 64-bit.  About a month ago (), I
> posted a message with the subject "Undefined Symbols in OSG on Mac OS X"
>
> The OSG binary installer for Mac OS X 10.4 (the 10.4u SDK) *mostly*
> worked, but my applications would not compile if I made calls to
> osg::Image::readPixels() or osg::StateSet::setMode().
>
> E. Wing replied that:
> =
> Yeah, Apple screwed up and broke binary compatibility between 10.4 and
> 10.5 when using OpenGL and C++. I have notes and binaries coming on
> this, but the short story is you can't use 10.4 built frameworks
> against the 10.5 SDK or you get the linking problems you see. Either
> switch to the 10.4u SDK on Leopard, or use a set of OSG frameworks
> built against the 10.5 SDK.
> =
>
> Anyway, once the Mac OS X 10.5 SDK (32-bit only) was released and I
> upgraded to it (http://www.openscenegraph.org/projects/osg/wiki/Downloads)
> it solved the linking problems I was having.
>
> If you look through the release notes for the 10.5 SDK, it mentions that
> Apple changes some of the types in the OpenGL headers, so OSG had to be
> rebuilt for that.
>   
Hi,

thanks for the info. But does that mean that I would avoid those 
problems by simply using Mac OS 10.4 ?

Regards,

Andreas

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] INHERIT_RENDERBIN_DETAILS

[Robert Osfield]

Hi John

I'm afraid there is too little info provided to know what might be up
and how to fix it.  StateSet::RenderBinDetails is what should be used
to control overall draw order, but you make not mention of this.

Robert.

On Dec 12, 2007 7:08 PM, Argentieri, John-P63223
<[EMAIL PROTECTED]> wrote:
>
>
>
> Hello all.
>
> We are using inherit renderbin details to assign a nested set of priorities.
> We have a group node with a top-level priority which contains several geodes
> with priorities using the inherit flag. Each of the geodes has a textured
> polygon geometry. We want to have the polygons depth test disabled and drawn
> in a certain order so that they will show the last drawn on top.
>
> OSG is not drawing these in order as it should. Any ideas what the problem
> might be? We haven't used the override renderbin details flag anywhere, so
> it is bizarre that things are happening this way. We can turn on blending
> and lower the alphas and see that both our polygons are there.
>
> John Argentieri
> Software Engineer
> GENERAL DYNAMICS
> C4 Systems
> (407) 281-5568
> [EMAIL PROTECTED]
>
> "This email message is for the sole use of the intended recipient(s) and may
> contain GDC4S confidential or privileged information. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not an
> intended recipient, please contact the sender by reply email and destroy all
> copies of the original message."
> ___
> 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] Restoring Mouse Pointer

[maruti borker]

Thanks for the cut-pasted code  :) ...

I have attached how i actually did it ..


On Dec 12, 2007 12:03 AM, Paul Speed <[EMAIL PROTECTED]> wrote:

>
>
> maruti borker wrote:
> >
> > Yes , even i wanted to have quake-type controls ... can u please copy
> > paste some example code so  that i can have an idea.
> >
>
> Ok, our code is part of a Java peer since we actually grab the mouse
> values from Java.  So I'll cut and paste the relevant stuff but don't be
> surprised if it it a little disjointed... oh, and ignore my funky
> bracing style...  (and errorf() and warnf() are our own calls into a
> logging API on the Java side.)
>
> In the header, we include:
>   #define DIRECTINPUT_VERSION 0x0800
>   #include 
>
> And add a field to the class:
>   LPDIRECTINPUTDEVICE8 g_pMouse;
>
>
> In the class implementation we have an initialize method that acquires
> access to the mouse device:
>
> HRESULT hr;
> LPDIRECTINPUT8   g_pDI= NULL;
> g_pMouse = NULL;
>
> // Create a DInput object
> hr = DirectInput8Create( GetModuleHandle(NULL), DIRECTINPUT_VERSION,
>  IID_IDirectInput8, (VOID**)&g_pDI, NULL );
> if( FAILED(hr) )
> {
> errorf( "Failed to initialize DirectInput: %i", hr );
> return( -1 );
> }
>
> // Obtain an interface to the system mouse device.
> hr = g_pDI->CreateDevice( GUID_SysMouse, &g_pMouse, NULL );
> if( FAILED(hr) )
> {
> errorf( "Failed to create mouse device: %i", hr );
> return( -1 );
> }
>
> // Set the data format to "mouse format" - a predefined data format
> //
> // A data format specifies which controls on a device we
> // are interested in, and how they should be reported.
> //
> // This tells DirectInput that we will be passing a
> // DIMOUSESTATE2 structure to IDirectInputDevice::GetDeviceState.
> hr = g_pMouse->SetDataFormat( &c_dfDIMouse2 );
> if( FAILED(hr) )
> {
> errorf( "Failed to set data format: %i", hr );
> return( -1 );
> }
>
> // By default we'll set the device to be in non-exclusive
> // mode until acquired.  Which actually is still pretty
> // much what we want other than the fact that regular events
> // still work.
> DWORD dwCoopFlags = DISCL_NONEXCLUSIVE | DISCL_FOREGROUND;
>
> HWND hWnd = GetForegroundWindow();
>
> // Set the cooperativity level to let DirectInput know how
> // this device should interact with the system and with other
> // DirectInput applications.
> hr = g_pMouse->SetCooperativeLevel( hWnd, dwCoopFlags );
> if( FAILED(hr) )
> {
> errorf( "Failed to set mouse cooperation mode: %i", hr );
> return( -1 );
> }
>
> // Acquire the non-exclusive device
> hr = g_pMouse->Acquire();
> if( FAILED(hr) )
> {
> errorf( "Mouse acquisition failed:%i", hr );
> return( -1 );
> }
>
> return( (int)0 );
>
>
> Then to read the mouse state we have a method for reading the device
> values that looks like:
>
> HRESULT   hr;
> DIMOUSESTATE2 dims2;  // DirectInput mouse state structure
>
> // Get the input's device state, and put the state in dims
> ZeroMemory( &dims2, sizeof(dims2) );
> hr = g_pMouse->GetDeviceState( sizeof(DIMOUSESTATE2), &dims2 );
> if( FAILED(hr) )
> {
> // We may have lost acquisition of the device because another
> // app went to the foreground.  Since we don't busy-wait for
> // it to come back we can't rely on the return code to tell us...
> // so we'll keep trying to reacquire for every error.
> if( hr == DIERR_INPUTLOST )
> warnf( "Mouse access lost." );
>
> // Try to reacquire it once
> hr = g_pMouse->Acquire();
> if( FAILED(hr) )
> {
> // Just return an empty state
> return( createMouseState( 0, 0, 0, 0, 0, 0 ) );
> }
> else
> {
> warnf( "Mouse access reacquired." );
> }
> }
>
>
> return createMouseState( dims2.lX, dims2.lY, dims2.lZ,
>  dims2.rgbButtons[0],
>  dims2.rgbButtons[1],
>  dims2.rgbButtons[2] );
>
> The create mouse state method call above is creating our own Java holder
> for the data.  I left it in because it takes all of the data members
> that are interesting.
>
> We have another method for acquiring exclusive and non-exclusive access
> to the mouse:
>
> void MousePeer::setAcquire(bool flag)
> {
> // Unacquire the mouse if we've grabbed it previously
> if( g_pMouse )
> {
> g_pMouse->Unacquire();
> }
>
> if( flag )
> {
> // Acquire exclusively
>
> // Right now we always do exclusive foreground mode
> // when we acquire.  This means that our app should h

Re: [osg-users] Unresolved symbol in FreeType plugin

[Jean-Sébastien Guay]

Hello Mike,

>> Note that you need to re-run cmake and change the lib names
>> for some of the new libs to be picked up, because either the
>> version number changed or they didn't have a version number before.
>
> Hi, pls do submit any necessary cmake mods.
> thanks

No, sorry I was not clear about what I meant... I meant that in the  
CMakeSetup window, since the old lib names were different from the new  
ones, you need to change them. So where for example it said

PNG_LIBRARY_DEBUG G:\...\3rdParty\libpngD.lib

I had to change it to

PNG_LIBRARY_DEBUG G:\...\3rdParty\libpng13D.lib

That's all. I think if you delete your CMakeCache.txt and re-do the  
cmake config, it'll detect the right ones. I'll check later, but since  
no one else noted anything I would assume it's fine.

Sorry for any confusion...

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] INHERIT_RENDERBIN_DETAILS

[Argentieri, John-P63223]

Hello all.

We are using inherit renderbin details to assign a nested set of
priorities. We have a group node with a top-level priority which
contains several geodes with priorities using the inherit flag. Each of
the geodes has a textured polygon geometry. We want to have the polygons
depth test disabled and drawn in a certain order so that they will show
the last drawn on top.

OSG is not drawing these in order as it should. Any ideas what the
problem might be? We haven't used the override renderbin details flag
anywhere, so it is bizarre that things are happening this way. We can
turn on blending and lower the alphas and see that both our polygons are
there.

John Argentieri
Software Engineer
GENERAL DYNAMICS
C4 Systems 
(407) 281-5568
[EMAIL PROTECTED]

"This email message is for the sole use of the intended recipient(s) and
may contain GDC4S confidential or privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited. If
you are not an intended recipient, please contact the sender by reply
email and destroy all copies of the original message."

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Unresolved symbol in FreeType plugin

[Mike Weiblen]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Jean-Sébastien Guay
> Sent: Wednesday, December 12, 2007 9:28 AM
> To: osg-users@lists.openscenegraph.org
> Subject: Re: [osg-users] Unresolved symbol in FreeType plugin

> Note that you need to re-run cmake and change the lib names 
> for some of the new libs to be picked up, because either the 
> version number changed or they didn't have a version number before.
> 
> J-S


Hi, pls do submit any necessary cmake mods.
thanks
-- mew
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgIntrospection: help on genwrapper...

[Emmanuel Roche]

Forget about this question too, I found the answer in the default
genwrapper.conf file:

configure reflector "vLog::Source"
configure method
"__void__log__wxString__wxString__wxString__wxString__..._S"
replace with ""
end
end

;-)

Manu.


2007/12/12, Emmanuel Roche <[EMAIL PROTECTED]>:
>
> It's okay, forget this, I found the source of the problem:
>
> it's because in my RefPtr class definition I had:
>
> RefPtr(const RefPtr& rp); as declaration of the copy constructor
>
> I changed this to RefPtr(const RefPtr& rp); and it did the trick !!
>
> But still, I have an other question : is there a way to tell the
> genwrapper not to take a given member function into account ? (maybe an
> option for the genwrapper.conf file ?)
>
> regards,
>
> Manu.
>
>
>
> 2007/12/12, Emmanuel Roche <[EMAIL PROTECTED]>:
> >
> > Hello everyone I've got a problem here with the result of genwrapper:
> >
> > here is an example of what I get:
> >
> > BEGIN_VALUE_REFLECTOR(vBase::RefPtr< vXML::Attribute >)
> > I_DeclaringFile("base/RefPtr.h");
> > I_Constructor0(RefPtr,
> >"",
> >"");
> > I_Constructor1(IN, vXML::Attribute *, p,
> >Properties::NON_EXPLICIT,
> >RefPtr__T_P1,
> >"",
> >"");
> > I_Constructor1(IN, const vBase::RefPtr< vXML::Attribute ><
> > vXML::Attribute > &, rp,
> >Properties::NON_EXPLICIT,
> >RefPtr__C5_RefPtrT1_T__R1,
> >"",
> >"");
> >
> > etc etc...
> >
> > The problem comes from the red section... as you can see, the templated
> > class is repeated !... If I correct this small problem, my wrappers compile
> > just fine... it would be a pity to renounce here, so I'm just about to check
> > where the problem may come from in GenWrapper sources... any indication
> > would be really appreciated if someone has an idea how to solve this.
> >
> > regards,
> >
> > Manu.
> >
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG version

[Robert Osfield]

On Dec 12, 2007 4:17 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> I've tested the most recent SVN successfully, except osgversion still
> displays "2.2.0" which is not correct. Otherwise, no problems so far.

Thanks for the testing and feedback.

I'll bump the version number up once I tag the 2.3.0 release, I've
been hanging back while more testing is carried out.

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OSG and Chromium

[syed tayyab]

Hi folks
I am a student and want to use OSG for my project , as part of my project i 
have to do parallel rendering over the grid or Cluster.
Does any one now the feasibility of this scenario. or any other combination.
Looking forward to hear from you.
Regards
Syed Tayyab
_
Telly addicts unite!
http://www.searchgamesbox.com/tvtown.shtml___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgIntrospection: help on genwrapper...

[Emmanuel Roche]

It's okay, forget this, I found the source of the problem:

it's because in my RefPtr class definition I had:

RefPtr(const RefPtr& rp); as declaration of the copy constructor

I changed this to RefPtr(const RefPtr& rp); and it did the trick !!

But still, I have an other question : is there a way to tell the genwrapper
not to take a given member function into account ? (maybe an option for the
genwrapper.conf file ?)

regards,

Manu.



2007/12/12, Emmanuel Roche <[EMAIL PROTECTED]>:
>
> Hello everyone I've got a problem here with the result of genwrapper:
>
> here is an example of what I get:
>
> BEGIN_VALUE_REFLECTOR(vBase::RefPtr< vXML::Attribute >)
> I_DeclaringFile("base/RefPtr.h");
> I_Constructor0(RefPtr,
>"",
>"");
> I_Constructor1(IN, vXML::Attribute *, p,
>Properties::NON_EXPLICIT,
>RefPtr__T_P1,
>"",
>"");
> I_Constructor1(IN, const vBase::RefPtr< vXML::Attribute ><
> vXML::Attribute > &, rp,
>Properties::NON_EXPLICIT,
>RefPtr__C5_RefPtrT1_T__R1,
>"",
>"");
>
> etc etc...
>
> The problem comes from the red section... as you can see, the templated
> class is repeated !... If I correct this small problem, my wrappers compile
> just fine... it would be a pity to renounce here, so I'm just about to check
> where the problem may come from in GenWrapper sources... any indication
> would be really appreciated if someone has an idea how to solve this.
>
> regards,
>
> Manu.
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OSG version

[Paul Martz]

I've tested the most recent SVN successfully, except osgversion still
displays "2.2.0" which is not correct. Otherwise, no problems so far.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
303 859 9466
 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgIntrospection: help on genwrapper...

[Emmanuel Roche]

Hello everyone I've got a problem here with the result of genwrapper:

here is an example of what I get:

BEGIN_VALUE_REFLECTOR(vBase::RefPtr< vXML::Attribute >)
I_DeclaringFile("base/RefPtr.h");
I_Constructor0(RefPtr,
   "",
   "");
I_Constructor1(IN, vXML::Attribute *, p,
   Properties::NON_EXPLICIT,
   RefPtr__T_P1,
   "",
   "");
I_Constructor1(IN, const vBase::RefPtr< vXML::Attribute ><
vXML::Attribute > &, rp,
   Properties::NON_EXPLICIT,
   RefPtr__C5_RefPtrT1_T__R1,
   "",
   "");

etc etc...

The problem comes from the red section... as you can see, the templated
class is repeated !... If I correct this small problem, my wrappers compile
just fine... it would be a pity to renounce here, so I'm just about to check
where the problem may come from in GenWrapper sources... any indication
would be really appreciated if someone has an idea how to solve this.

regards,

Manu.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] intermediate osg training: washington dc, jan 22/23 (osg terrain on 01/24)

[Bob Kuehne]

hi gang,

just a reminder about paul and my forthcoming osg training this  
january in washington dc. what better way to celebrate the holidays  
than by getting a loved one an osg training? give a man a polygon,  
he'll render for a day, teach him to tessellate, and he'll render for  
the rest of his life. or something like that.

anyway, we've got a nice group of students already, but space is still  
available. so, join us in the heart of washington dc, with easy access  
to the metro and parking, and we'll provide all the coffee you'll  
need. here's what we'll be teaching:

january 22 & 23: OSG intermediate course

we'll teach you everything you need to know to move from basic OSG  
usage, to advanced things like building custom drawables, plugins,  
etc. here's what you'll learn:

  * Memory management
  * Nodes, various node types, custom nodes and NodeKits
  * Traversals, NodeVisitors, Callbacks
  * Data manipulation tools
  * Drawables, Geometry, and state
  * Using plugins
  * Threads
  * Viewing and camera manipulation
  * Window system integration
  * Optimization techniques

january 24: terrain databases in OSG

and of course, our bonus round this year is a terrain day. we'll teach  
you how to build the world, and deal with thorny issues of scale.  
specifically:

  * Large data set construction, display, and optimization
  * Paged data sets
  * Network served data
  * VirtualPlanetBuilder data generation
  * Shading
  * Tools & Workflow

we hope you can join us!

bob

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenFlight Continuation Record support

[Paul Martz]

Hi Brede -- Tested this morning and Continuation record support works well
in current SVN. Thanks for your help with this.
   -Paul



> Hi Paul,
> 
> I have added support for the continuation record to the 
> OpenFlight reader.  The implementation now reads the record 
> to memory with one read operation and creates a string stream 
> for parsing.  I could replace have-I-reach-the-end-of-record 
> tests with eof() or good() simplifying the code.
> 
> Update the latest version from SVN with the attached files.
> 
> Please test if something is broken or the read performance 
> have changed.
> 
> Regards,
> Brede
> 
> 
> 
> On Dec 7, 2007 10:44 AM, Brede Johansen <[EMAIL PROTECTED]> wrote:
> > Hi Paul,
> >
> > The continuation record is one of the things in the OpenFlight 
> > specification that adds a bit of grey to your hair color.
> > I didn't have the need for this record at the time so I left it out 
> > together with a lot of other records.
> >
> > That said I did some thinking on how to support it.  The current 
> > implementation is stream based so it's possible to add a layer that 
> > hides the continuation record using a memory buffered stream.  The 
> > VertexPool already do this by inheriting from std::istringstream.
> > I'll have a look at it.
> >
> >
> > Regards,
> > Brede
> >
> >
> >
> > On Dec 6, 2007 10:56 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Hi Brede -- I see the current OpenFlight importer doesn't support 
> > > Continuation Records. I haven't looked at what it would 
> take to add 
> > > it, but wondered what your thoughts were? Was this left 
> out because 
> > > it wasn't a requirement, or because it didn't fit into the design?
> > >
> > > I'm finding I need it for large LocalVertexPool records. 
> I wonder if 
> > > it could be supported on a record-by-record basis... Thoughts?
> > >
> > > Paul Martz
> > > Skew Matrix Software LLC
> > > http://www.skew-matrix.com
> > > 303 859 9466
> > >
> > > ___
> > > osg-users mailing list
> > > osg-users@lists.openscenegraph.org
> > > 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegrap
> > > h.org
> > >
> > >
> >
> 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Obtaining the contextID

[Robert Osfield]

On Dec 12, 2007 3:28 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> > This feels like a case of "I need this for my particular code
> > so OSG should have a core feature supporting it"... just so
> > you personally can save a bit of coding.
>
> Actually, I've already coded a workaround, so your feeling is wrong. This is
> just a case of something I'm able to do in OpenGL that I notice isn't
> possible in OSG.

OpenGL uses a state model.  OSG is a retained model.

They are very different models for managing data.  Doing get/sets of
current global state is appropriate for OpenGL, its not appropriate
for the OSG.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Raytracing status

[Jean-Sébastien Guay]

Hello Michele,

> Thank you Jean, Adrian was kind enough to send me already its code, I
> am reviewing it now :)

Good, I don't have access to my home machine so I would have sent it  
to you in a few hours... :-)

> I was thinking, maybe it wouldn't be a bad idea to integrate YafRay
> into OSG, the license (LGPL) seems ok with it, unlike POV-Ray.

When I started my Masters, my first attempt was to try and make an  
interface between OSG and Yafray. Unfortunately, the main developer  
(Lynx) was not very open to requests to changes in the build system  
and other things that would have made this kind of development easier.  
He seemed to just want to do his thing, not really wanting external  
programs to use Yafray code directly (but that may just be an  
impression - take it with a grain of salt).

In the end, I just used OSG's IntersectionVisitor and eventually  
Adrian's kd-tree. I didn't really need advanced effects, just  
intersection testing, so that was enough. But if Lynx can be brought  
on to help do a real integration of Yafray with OSG with the goal of  
doing some realtime raytracing, that may be really interesting.

If the question is which Open Source raytracer would be the best to  
try such an integration, Yafray is definitely my first choice. It's  
really fast, and gives very good results.

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Specifying the LOD for an intersection testing

[Thrall, Bryan]

Eyal Raab wrote on Wednesday, December 12, 2007 6:25 AM:
> Hi,
> 
> * Can someone point me to an explanation on how LOD is used in
>   intersection testing?
> * When doing intersection testing, can I specify the LOD for the
>   testing?
> * I'm trying to find all of the drawable objects that fit inside a
>   given PolytopeIntersector but that appear only at a given LOD
>   range ( I'm only interested in the highest resolution drawables
>   objects ).

See osgUtil::IntersectVisitor::LODSelectionMode. osg::LOD uses the
getDistanceToEyePoint function to determine which child to visit, so the
visitor can influence what LOD is used by how it implements that
function. The LODSelectionMode type lets you always select the highest
level of detail, but there isn't an option for a specific range of LODs
(which would be tricky anyway, since you never know how many levels are
available in a particular scenegraph!).

Basically, IntersectVisitor acts just like any other NodeVisitor when it
comes to an LOD; it's just that the LOD either thinks the eyepoint is
right next to it (IntersectVisitor::USE_HIGHEST_LEVEL_OF_DETAIL), or
that the eyepoint is at the _pseudoEyePoint (which is set to the start
point of the last segment added via addLineSegment())
(IntersectVisitor::USE_SEGMENT_START_POINT_AS_EYE_POINT_FOR_LOD_LEVEL_SE
LECTION).

If you need different LOD behavior than that, you could probably
subclass IntersectVisitor and override getDistanceToEyePoint() to get
the behavior you need.

Hope this helps,
-- 
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] Unresolved symbol in FreeType plugin

[Robert Osfield]

Hi Paul,

On Dec 12, 2007 3:21 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> I'm getting this with current SVN and VS2005. Do I need to update my 3rd
> party dependencies?

So the missing symbol is _FT_Outline_Get_BBox?  I can see a
FT_Outline_Get_BBox entry in the FreeTypeFont3D::init() method, so
presume this is related.  I don't know how far back this function is
supported, the freetype version I have installed is:

freetype-config --version
9.16.3

Could you check up for the existence of this method in the freetype
version you have.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Development-system for Mac-OS

[Berg, Michael]

I don't think the problems weren't just 64-bit.  About a month ago (), I
posted a message with the subject "Undefined Symbols in OSG on Mac OS X"

The OSG binary installer for Mac OS X 10.4 (the 10.4u SDK) *mostly*
worked, but my applications would not compile if I made calls to
osg::Image::readPixels() or osg::StateSet::setMode().

E. Wing replied that:
=
Yeah, Apple screwed up and broke binary compatibility between 10.4 and
10.5 when using OpenGL and C++. I have notes and binaries coming on
this, but the short story is you can't use 10.4 built frameworks
against the 10.5 SDK or you get the linking problems you see. Either
switch to the 10.4u SDK on Leopard, or use a set of OSG frameworks
built against the 10.5 SDK.
=

Anyway, once the Mac OS X 10.5 SDK (32-bit only) was released and I
upgraded to it (http://www.openscenegraph.org/projects/osg/wiki/Downloads)
it solved the linking problems I was having.

If you look through the release notes for the 10.5 SDK, it mentions that
Apple changes some of the types in the OpenGL headers, so OSG had to be
rebuilt for that.

- Michael


Stephan Maximilian Huber wrote:
> Andreas Goebel schrieb:
>> I am about to buy a mac to port my osg-based application to mac-os. One 
>> simple question: I read about compatibility-problems with the new Mac-OS 
>> (10.5, I think).
>>   
> The reported problems are for 64bit only. If you stick with the 10.4-sdk 
> (which is 32bit) osg works out of the box on Leopard (10.5) and Tiger (10.4)
> 
>> Would it be better to buy a Mac running Mac-OS 10.4, and would programs 
>> compiled with this Mac more likely run on older and newer Mac´s?
>>   
> osg needs IMHO 10.4 at minimum, so osg-programs should run on every mac 
> with that system.
> 
> 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] Unresolved symbol in FreeType plugin

[Serge Lages]

Hi,

On Dec 12, 2007 4:21 PM, Paul Martz <[EMAIL PROTECTED]> wrote:

> I'm getting this with current SVN and VS2005. Do I need to update my 3rd
> party dependencies?
>   -Paul
>

Seems you have to update yes, my freetype plugin build without any problem.
Take the last 3rd party version from Mike's SVN.


>
>
> 2>-- Build started: Project: Plugins freetype, Configuration: Release
> Win32 --
> 2>Linking...
> 2>FreeTypeFont3D.obj : error LNK2019: unresolved external symbol
> _FT_Outline_Get_BBox referenced in function "protected: void __thiscall
> FreeTypeFont3D::init(void)" ([EMAIL PROTECTED]@@IAEXXZ)
>
> ___
> 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] osgvolumed usage

[R. Aditya Kadambi]

On Dec 12, 2007 2:42 AM, Robert Osfield <[EMAIL PROTECTED]> wrote:

> Does you source data have alpha values in it


They apparently didn't have. I then tried using data from the
OpenSceneGraph-Data/Images/tree0.rgba which has alpha values.

At this stage I am just interested in seeing a solid block. Here is what I
did.
I made copies of tree0.rgba file to say, tree1.rgba and:

$ osgvolumed --images tree0.rgba tree1.rgba

I still don't see a solid block. The result is still like a single slice. Do
I have to specify a direction to stack images on?

Thanks.


>
> On Dec 11, 2007 9:07 PM, R. Aditya Kadambi <[EMAIL PROTECTED]> wrote:
> > I am trying to use it like this now. But I can't find a way to set alpha
> > value from the help menu.
> >
> > $ ./osgvolumed --images file.1png file2.png
> >
> > I don't see a volume stack. Any suggestions?
> >
> > Thanks.
> >
> >
> >
> > On Dec 11, 2007 9:40 AM, R. Aditya Kadambi <[EMAIL PROTECTED]> wrote:
> > > Hi Robert;
> > >
> > > Thanks. So, would this usage be valid:
> > >
> > > $ osgvolumed --images *.png --alpha 
> > >
> > > Thanks,
> > >
> > >
> > >
> > >
> > >
> > > On Dec 11, 2007 2:04 AM, Robert Osfield < [EMAIL PROTECTED]>
> wrote:
> > >
> > > > HI Aditya,
> > > >
> > > > You need to use data with a alpha value, or intensity data otherwise
> > > > you'll just end up with a solid block.
> > > >
> > > > Robert.
> > > >
> > > >
> > > >
> > > >
> > > > On Dec 11, 2007 3:30 AM, R. Aditya Kadambi <[EMAIL PROTECTED]>
> wrote:
> > > > > I am trying to use the "osgvolumed" from the examples program. I
> am
> > looking
> > > > > for sample data to use it (2d or 3d).
> > > > >
> > > > > If I wish to use a stack of 2d images, the help menu says, I need
> to
> > do
> > > > > this:
> > > > >
> > > > > $osgvolumed --images 
> > > > >
> > > > > I tried to use stack of *.png or *.rgb images and don't see the
> volume
> > > > > construction. Can someone point me to sample data and the data
> type to
> > be
> > > > > used for this program. Also, what are the
> > > > > 3d image formats I can use.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > ___
> > > > > 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] Unresolved symbol in FreeType plugin

[Jean-Sébastien Guay]

Hello Paul,

> I'm getting this with current SVN and VS2005. Do I need to update my 3rd
> party dependencies?

After updating yesterday I got that same problem, and updating the  
dependencies to Mike's latest on his SVN (which is freetype235 instead  
of freetype219) fixed it. I wonder though why the function would be in  
the headers of the old dependencies (because it compiled) but not in  
the lib (because it didn't link)... But anyhow, problem solved :-)

Note that you need to re-run cmake and change the lib names for some  
of the new libs to be picked up, because either the version number  
changed or they didn't have a version number before.

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Obtaining the contextID

[Paul Martz]

> This feels like a case of "I need this for my particular code 
> so OSG should have a core feature supporting it"... just so 
> you personally can save a bit of coding.

Actually, I've already coded a workaround, so your feeling is wrong. This is
just a case of something I'm able to do in OpenGL that I notice isn't
possible in OSG.
   -Paul

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Raytracing status

[Michele Bosi]

Thank you Jean, Adrian was kind enough to send me already its code, I
am reviewing it now :)
Hope to hear from you as soon as possible about OSG realtime ray tracing though!

I was thinking, maybe it wouldn't be a bad idea to integrate YafRay
into OSG, the license (LGPL) seems ok with it, unlike POV-Ray. If not
a real integration maybe an utility class would be already
interesting: this class would parse the OSG nodes, convert them into
YafRay data and output the rendered image. Dunno this is just a raw
idea that I put here so if some YafRay guru is between us we can be
all enlighted :)

Regards,
Michele
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Solaris compilation issues in SVN

[Andy Skinner]

Here are some compilation fixes I ran into.

andy

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Wednesday, December 12, 2007 5:00 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Solaris compilation issues in SVN

Hi Andy,

Yesterday I merged a submission to DatabasePager.cpp that included use
of various stl alogorithms - such as sort and find and others, the
submission added a using namespace std, but I don't like importing
whole namespaces so I removed the code and then added std:: where
appropriate, clearly I missed a few.  I've just done a search for find
and sort and added std:: in the appropriate places.  I may have missed
a few though, could you do a svn update and let me know how you get
on.

Robert.

On Dec 11, 2007 7:34 PM, Andy Skinner <[EMAIL PROTECTED]>
wrote:
> I'm looking for the same kinds of things we've been struggling with in
> the past--standard template library functions that aren't in the
solaris
> compiler's headers.
>
> We've fixed them in the past by adding includes to stdlib.h or
similar.
> I am looking at a couple in DatabasePager.cpp.  I could try to fix
them
> in a similar way, but I notice that there are occurrences of these
> functions with std:: in front of them.  For example, one call to
find()
> is std::find(...), and another is just find(...).  The first compiles
> for me, the second doesn't.
>
> At my company, we would address this with the std:: prefix.  But I
> thought we didn't want to do that in the OSG.
>
> Should I address these with std::, as other calls in this file do?  Or
> remove the std:: from the other calls and find the right include to
fix
> it?
>
> andy
>
> ___
> 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.or
g


fixes.tar.gz
Description: fixes.tar.gz
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Unresolved symbol in FreeType plugin

[Paul Martz]

I'm getting this with current SVN and VS2005. Do I need to update my 3rd
party dependencies?
   -Paul


2>-- Build started: Project: Plugins freetype, Configuration: Release
Win32 --
2>Linking...
2>FreeTypeFont3D.obj : error LNK2019: unresolved external symbol
_FT_Outline_Get_BBox referenced in function "protected: void __thiscall
FreeTypeFont3D::init(void)" ([EMAIL PROTECTED]@@IAEXXZ)

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Obtaining the contextID

[Robert Osfield]

On Dec 12, 2007 2:52 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> However, my post below expressed concern that there was no way to access the
> current contextID at a global level. There's no equivalent of
> glXGetCurrentContext in OSG, for example. It seems like, if a context is
> current in the active thread, OSG should provide a global method for
> obtaining its contextID, analogous to what GLX, WGL, AGL, etc., all
> provide...?

This feels like a case of "I need this for my particular code so OSG
should have a core feature supporting it"... just so you personally
can save a bit of coding.

A contextID is pretty useless without more information about what the
contextID is associated with - and the contextID can even be shared
between contexts so its not even a unique way of determining what
graphics context you are associated with.

All the traversals that are tied to specific graphics contexts already
have access to the osg::State object - both the cull and the draw, and
this applies to whether you use SceneView, osgViewer, osgProducer or
whatever you roll yourself.  My feeling is that with a bit of
consideration it should be easy to do what you want without grafting
globals into the OSG.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Obtaining the contextID

[Paul Martz]

> Hi Paul,
> 
> The contextID is stored in the osg::State, SceneView has a 
> State and therefore the ContextID.  The osg::Camera without 
> any graphics context doesn't though as its through the 
> GraphicsContext that it gets its State.
> 
> Workarounds for you would be to create a dummy 
> GraphicsContext for each window that the apps opens and make 
> this GraphicsContext share the SceneView's State.  
> Alternatively you could have a hack where you register a 
> callback to get the contextID given a Camera, then an 
> application specific custom callback could implement a 
> mapping between the Camera and the appropriate SceneView and 
> then finally to the ContextID.
> 
> Robert.

Thanks, these are good suggestions, and I believe I can find a workaround
quite easily.

However, my post below expressed concern that there was no way to access the
current contextID at a global level. There's no equivalent of
glXGetCurrentContext in OSG, for example. It seems like, if a context is
current in the active thread, OSG should provide a global method for
obtaining its contextID, analogous to what GLX, WGL, AGL, etc., all
provide...?
   -Paul

> 
> On Dec 11, 2007 7:18 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> >
> >
> > Hi Robert -- I'm working with an older app that deals directly with 
> > SceneView. It effectively creates its own window and 
> manages its own 
> > graphics contexts.
> >
> > I've found this app doesn't work with osgOQ. osgOQ uses a 
> Camera post 
> > draw callback to retrieve the query results, and therefore 
> needs the 
> > abstract unsigned int contextID. To get this, it uses the 
> following code:
> > camera.getGraphicsContext()->getState()->getContextID().
> >
> > The only problem is that the app never set up a 
> GraphicsContext on the 
> > SceneView's Camera. SceneView doesn't do this itself (of course -- 
> > it's ignorant of contexts).
> >
> > Note that osgOQ can get the contextID just fine in other 
> parts of the 
> > code, such as in a CullVisitor traverse() call, or in a 
> draw callback 
> > or drawImplementation(). The contextID is readily available from 
> > RenderInfo::getState(). It's just the Camera post draw 
> callback that 
> > is the problem, because I must go through the Camera's 
> (non-existent) 
> > GraphicsContext to get State.
> >
> > It seems like, somewhere, there should be a mapping of 
> actual platform 
> > rendering context IDs to OSG's abstract unsigned int 
> contextID, such 
> > that, if a context is actually current, code should be able 
> to look up 
> > the abstract unsigned int contextID in a map somewhere. I've been 
> > unable to locate any such construct in OSG.
> >
> > I'm certain you'll recommend porting to osgViewer, but telling my 
> > client that the previously-supported OSG interface they coded to is 
> > incompatible with osgOQ isn't really an option. So, if 
> there's no way 
> > for me to get a contextID from a Camera that doesn't have a 
> > GraphicsContext, then I'll have to look into alternate 
> implementations for osgOQ.
> >
> > Paul Martz
> > Skew Matrix Software LLC
> > http://www.skew-matrix.com
> > 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-opensce
negraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] image format conversion

[Gerrick Bivins]

Hi Robert,Yup. This is what I eventually ended up doing. I hadn't previously
known the exact
usage for the "internal format" parameter when specifying textures in GL but
after some digging last night I figured it out.
Anyway, thanks!
biv
On Dec 12, 2007 3:54 AM, Robert Osfield <[EMAIL PROTECTED]> wrote:

> Hi Gerrick,
>
> You could play with using the Texture::setInternalFormat(GLint) method.
>
> Robert.
>
> On Dec 12, 2007 12:07 AM, Gerrick Bivins <[EMAIL PROTECTED]> wrote:
> > Hi all,
> > I think I know the answer but just in case I'm overlooking something I
> > thought I'd ask.
> > What is the most efficient way to convert the osg::Image loaded from
> > osgDB::readImageFile() to another format, specifically RGBA 32-bit
> > floating-point for use
> > in a vertex shader? I can do a "brute force" method but if there's a
> better
> > way, I'd go for that.
> > biv
> > ___
> > 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] Raytracing status

[Jean-Sébastien Guay]

Hello Michele,

> I am totally not a ray tracing guru, but I would like to have a look
> at the code of Adrian to have an idea, where can I find it? Is there
> any demo or usable working test of it?

I will send you the latest code and demo he sent me off-list.

Thanks,

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Warning in latest SVN

[Jean-Sébastien Guay]

Hello Robert,

> Hi J-S, Paul Martz sent the fix into osg-submissions, I merged this
> first thing when I booted up my machine this morning, an svn update
> will get this fix.

I saw that, thanks! (and to Paul too!)

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] problems with static builds on windows

[Stephan Maximilian Huber]

Robert Osfield schrieb:
> Hi Stephan,
>
> I'm not CMake guru that I'd like to be so I can't right away decide
> whether your change is appropriate or not.
>
> Could those more expert in CMake through some light on this matter?
>   
Yes please!

It seem's that I am the only soul on this list using static osg-libs 
under windows. If that's true then you can apply my patch, because it 
affects the build only  when static linking under windows is checked ;-)


cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] is possible to replace the graphic context???

[David _]

Hi

Right now i need to replace the camera graphic context in execution time and 
i´m doing this code

osg_viewer->getCamera()->setGraphicsContext(new_graphic_context);

when the new graphic context has a different size than the previous one, 
strange things start to happen like loosing some objects and textures and 
finally loosing the scene but i still can see the opengl canvas cause all the 
window is painted using it´s background clear color.

do i have to do anything else for replacing the graphic context???

thanks





_
Tecnología, moda, motor, viajes,…suscríbete a nuestros boletines para estar 
siempre a la última
http://newsletters.msn.com/hm/maintenanceeses.asp?L=ES&C=ES&P=WCMaintenance&Brand=WL&RU=http%3a%2f%2fmail.live.com___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Specifying the LOD for an intersection testing

[Eyal Raab]

Hi,

* Can someone point me to an explanation on how LOD is used in
  intersection testing?
* When doing intersection testing, can I specify the LOD for the
  testing?
* I'm trying to find all of the drawable objects that fit inside a
  given PolytopeIntersector but that appear only at a given LOD
  range ( I'm only interested in the highest resolution drawables
  objects ).

Something like:


picker = new osgUtil::PolytopeIntersector( 
osgUtil::Intersector::MODEL,  polytypeDesc );
osgUtil::IntersectionVisitor iv( picker );

// Set the level of detail for the intersection testing
osg::ref_ptr lod = new osg::LOD();

   

// Configure the lod object.

// 

   

iv.apply( *lod );

root->accept( iv );


Thanks in advance,

Eyal.

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Development-system for Mac-OS

[Stephan Maximilian Huber]

Andreas Goebel schrieb:
> I am about to buy a mac to port my osg-based application to mac-os. One 
> simple question: I read about compatibility-problems with the new Mac-OS 
> (10.5, I think).
>   
The reported problems are for 64bit only. If you stick with the 10.4-sdk 
(which is 32bit) osg works out of the box on Leopard (10.5) and Tiger (10.4)

> Would it be better to buy a Mac running Mac-OS 10.4, and would programs 
> compiled with this Mac more likely run on older and newer Mac´s?
>   
osg needs IMHO 10.4 at minimum, so osg-programs should run on every mac 
with that system.

cheers,
Stephan

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] AnimTK

[Cedric Pinson]

Ok to be clear, Loic, Igor and me (Cedric Pinson) worked on cal3d and 
osgcal(GPL) for pok3d. We
don't want anymore use cal3d for futur project so animtk is a try to 
open the ways. But it's a long
way to have something stable, functionnal, easy to use. So right now 
animtk can't replace cal3d/osgcal and
for a long time i think.
The idea on animtk is to make something general usable with osg or without:

building low level block like sampler, interpolator, (used to varying a 
data over time)
so it can be used to varying a vec4, a float, a quaternion, ... without 
interpreting the result.
like getValue(t). Here there is no loop mode , ping pong ... just a 
clamp if outside of range

 From these block we can make more complex structure like Animation, eg
Assembling a Sampler for a quaternion and a Sampler for a Vec3, then you 
can play
the animation with a manager that can blend them if more than two at the 
same time
and can set play mode like loop.

Skeleton feature has just started, the idea is to have just a hierarchy 
of transform that contain result of
sampler inside. The animation system does know what a skeleton or 
skinning is. eg:
ManagerAnimation.update(); // update animation
Skeleton.update(); // update the skeleton

I did not start the skinning part yet. But i want things separated to 
let the user control or override each part.

That's a project so today it can be use for a low level use (Sampler) i 
already used it in project. But it's a very
young project and so much thing to do, i am alone on it and not at full 
time so :)

If people wants to help :)


Jeremy Moles wrote:
> With all the recent discussion over Cal3D I decided to take a few
> minutes and look over some of the affiliated stuff at Gna.org and I
> found a project called AnimTK. The memberlist includes Loic Dachary (who
> also posts here from time to time and is/was pretty much the lead Cal3D
> guy) and Cedric Pinson (who also posts here), so I'm curious what this
> is and what it does, as it seemed to both use and be heavily influenced
> by OSG (naturally).
>
> ___
> 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

[osg-users] osgAnimation

[Robert Osfield]

Hi All,

I am posting this message to help start a new home for the discussions
about the proposal of adding character animation support into the core
OSG. So please post here rather than tagging on the 2.4 discussion
list.

My own current thoughts are:

1) Long term provide a general character/object animation NodeKit.

2) Aiming too long term can lead to never getting to the final
destination, so need to get something basic started first, don't
expect perfection right away.

3) Need to consider naming carefully as well as backwards
compatibility, personally I feel a break in NodeKit naming is required
to avoid potential confusion w.r.t backwards compatibility and to
avoid problems with various Linux distributions that hold
older variants like osgCal in their repositories.   I'd suggest go
for osgAnimation from the point of integration.

4) Integrate the latest incarnation of the LGPL'd osgCal as the first
stop basis of osgAnimation.  Possibly refactor so that Cal3D
dependencies are moved out to an optional plugin if time allows.
CMake support can be added at point of integration.

5) Avoid having too many NodeKits which do similar things, so
osgSkeleton etc. functionality would just be a component of
osgAnimation.


O.k. that's enough for now, over to you :)

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Development-system for Mac-OS

[Andreas Goebel]

Hi,

I am about to buy a mac to port my osg-based application to mac-os. One 
simple question: I read about compatibility-problems with the new Mac-OS 
(10.5, I think).

Would it be better to buy a Mac running Mac-OS 10.4, and would programs 
compiled with this Mac more likely run on older and newer Mac´s?

Sorry to ask this slightly offtopic question, but the people here are 
the most likely to know this.

Regards,

Andreas
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] readFontFile possible bug

[Robert Osfield]

Hi Serge,

On Dec 12, 2007 11:08 AM, Serge Lages <[EMAIL PROTECTED]> wrote:
> The readRefNodeFile seems a good option, moving the criticals readNodeFile
> to it. The osgText part will need a little bit more of refactoring, moving
> all the part where a C pointer is passed to a ref_ptr.
> If you want I can do the changes this afternoon if we decide to go this way.
> :)

A volunteer, great :-)

This would really help, as you are able to reproduce the crash, doing
these changes will hopefully allow you to test things directly.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] readFontFile possible bug

[Serge Lages]

On Dec 12, 2007 11:34 AM, Robert Osfield <[EMAIL PROTECTED]> wrote:

> Hi Serge,
>
> Thanks for the explanation, this really does help.  You suggest change
> to DatabasePager.cpp to use ReadResult rather than
> osgDB::readNodeFile() is an interesting one.  While the getting the
> timing to reproduce the crash seems pretty rare it is certainly
> possible, but often any little opening for a multi-threading crash can
> come out and bite, even if its seems really unlikely.
>
> My current though is the weakness you've highlights is that
> osgDB::readNodeFile() doesn't return a ref_ptr<>, opening the door to
> the object being unref'd at the same time as the C pointer is be
> passed back from readNodeFile.   Changing readNodeFile to pass back a
> ref_ptr<> is a possibility, but it'd break a lot of user code - this
> might be the right thing to do in terms of writing robust C++, but it
> is a heavy hit to force on users that don't code stuff in ways that
> would be sensitive to this issue.
>
> Perhaps a readRefNodeFile that passes back a ref_ptr<> would be a
> workaround.  I guess one might be able to write a little class to work
> as adapter too so one could pass this object back and it work for C*
> as well as ref_ptr<> but this would be a pretty obscure use of C++.
>
> Thoughts?
>
>
The readRefNodeFile seems a good option, moving the criticals readNodeFile
to it. The osgText part will need a little bit more of refactoring, moving
all the part where a C pointer is passed to a ref_ptr.
If you want I can do the changes this afternoon if we decide to go this way.
:)

-- 
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] Tablet-Events

[Stephan Maximilian Huber]

Daniel Moos schrieb:
> Hello Everybody
>
> I want to use the tablet-events (ERASER and PEN) for my application.
> But the only class, which uses this Tablet-Events is the GraphicsWindowCarbon 
> class. This class is only used on apple-computers. Is this right?
>
> Can i get tablet-events on linux and windows?

Currently Tablet-Events are only supported for OS X (Apple) -- for other 
platforms it has to be implemented.

sorry,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] where to find data/Earth/model.ive

[Wasilios Goutas]

Hi Robert,

ok it isn't ported to a new location, but it should still exist I think. 
Where can I find it?

I isn't refenced on the web, but inside an example code of the OSG Quick 
Start Guide  http://www.osgbooks.com/books/osg_qs.html
downloaded from http://www.skew-matrix.com/OSGQSG/

bye
wasili

Robert Osfield schrieb:
> Hi Wasili,
>
> I'm afraid Earth/model.ive paged database didn't get ported across to
> the new website.
>
> Is this file referenced on the osg website?  If so could you point me
> to the page so I can remove this dangling reference.
>
> Robert.
>
> On Dec 12, 2007 10:15 AM, Wasilios Goutas <[EMAIL PROTECTED]> wrote:
>   
>> Hi,
>>
>> I'm new to OpenGL and to oswg.
>> I downloaded the osg quick start guid and the example code and read
>> inside the viewermain.cpp following:
>> // TBD. Waiting for this file to get a permanent location after
>> //   the dimain name shuffle. THis is a better example than the
>> //   cow because it shows off the .net loader.
>> //viewer.setSceneData( osgDB::readNodeFile(
>> //"http://www.openscenegraph.org/downloads/data/Earth/model.ive";
>> ) );
>>
>> this path to model.ive does not exist.
>> Where can I find this earth model?
>>
>> bye
>> Wasili
>>
>>
>> ___
>> 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] where to find data/Earth/model.ive

[Robert Osfield]

Hi Wasili,

I'm afraid Earth/model.ive paged database didn't get ported across to
the new website.

Is this file referenced on the osg website?  If so could you point me
to the page so I can remove this dangling reference.

Robert.

On Dec 12, 2007 10:15 AM, Wasilios Goutas <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm new to OpenGL and to oswg.
> I downloaded the osg quick start guid and the example code and read
> inside the viewermain.cpp following:
> // TBD. Waiting for this file to get a permanent location after
> //   the dimain name shuffle. THis is a better example than the
> //   cow because it shows off the .net loader.
> //viewer.setSceneData( osgDB::readNodeFile(
> //"http://www.openscenegraph.org/downloads/data/Earth/model.ive";
> ) );
>
> this path to model.ive does not exist.
> Where can I find this earth model?
>
> bye
> Wasili
>
>
> ___
> 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] readFontFile possible bug

[Robert Osfield]

Hi Serge,

Thanks for the explanation, this really does help.  You suggest change
to DatabasePager.cpp to use ReadResult rather than
osgDB::readNodeFile() is an interesting one.  While the getting the
timing to reproduce the crash seems pretty rare it is certainly
possible, but often any little opening for a multi-threading crash can
come out and bite, even if its seems really unlikely.

My current though is the weakness you've highlights is that
osgDB::readNodeFile() doesn't return a ref_ptr<>, opening the door to
the object being unref'd at the same time as the C pointer is be
passed back from readNodeFile.   Changing readNodeFile to pass back a
ref_ptr<> is a possibility, but it'd break a lot of user code - this
might be the right thing to do in terms of writing robust C++, but it
is a heavy hit to force on users that don't code stuff in ways that
would be sensitive to this issue.

Perhaps a readRefNodeFile that passes back a ref_ptr<> would be a
workaround.  I guess one might be able to write a little class to work
as adapter too so one could pass this object back and it work for C*
as well as ref_ptr<> but this would be a pretty obscure use of C++.

Thoughts?
Robert.

On Dec 12, 2007 9:28 AM, Serge Lages <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
>
> On Dec 11, 2007 8:59 PM, Robert Osfield <[EMAIL PROTECTED]> wrote:
>
> > Hi Serge,
> >
> > How reliably can you recreate the crash?
> >
> > Does it happen with osgviewer or other OSG examples?
> >
> > Could you explain whats happening in your app before the crash.
> >
>
>
> Here is the context of the crash :
>
> DatabasePager configuration :
> pager->setExpiryDelay(5);
> pager->setUnrefImageDataAfterApplyPolicy(true, true);
> pager->setDeleteRemovedSubgraphsInDatabaseThread(false);
> pager->setMaximumNumOfRemovedChildPagedLODs(50);
> pager->setMinimumNumOfInactivePagedLODs(0);
>
> Registry configuration :
> osgDB::Registry::instance()->getOptions()->setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL);
>
> To make it crash, I have a custom manipulator which randomely move into a
> very high paged database (lots of giga). The database contains nodes with
> simple geometries but also texts. Sometime it crashs after hours of
> randomely moves, sometime after just 1 or 2 minutes. The crash happens in
> two locations :
>
> 1 - into osgText::Text::setFont (Text.cpp line 119) because the variable
> "font" is a corrupted pointer.
> 2 - into databasepager.cpp (line 604), during the initialization of
> databaseRequest->_loadedModel, because the pointer returned by readNodeFile
> is corrupted.
>
> These crashs happen into the pager thread, and the main thread is always
> into the removeExpiredSubgraphs method at this moment. In both cases, we
> have a very short laps of time where a C pointer is used for an object
> instead of a ref_ptr.
>
> For the crash number 2, it seems that switching readNodeFile by a readNode
> fix it. But I think that the better solution will be to prevent any cache
> clear during the readNodeFile call into databasepager.cpp, I will
> investigate further this morning and see if I can fix it.
>
> >
> > If we can work out the conditions that the crash happens we'll have a
> > much better chance of isolation. It could be as your describe an
> > object be deleted just when another thread is about to take a ref to
> > it, I would have thought this would be a pretty rare condition though.
> >
> > Robert.
> >
> >
> >
> >
> > On Dec 11, 2007 3:55 PM, Serge Lages <[EMAIL PROTECTED]> wrote:
> > > I have another theory about the crash, let's say that :
> > >
> > >
> > > osg::Object* object = osgDB::readObjectFile(foundFile, userOptions ?
> > > userOptions : localOptions.get());
> > >
> > > read the object from the cache, and between this moment and the one
> where
> > > the font object is set to a ref_ptr into setFont, the cache is cleared
> (into
> > > another thread). With this scenario the pointer points to a deleted
> object
> > > or is there anything to prevent it ?
> > >
> > > In my case this scenario is possible as I load my IVE with the
> databasepager
> > > and that I remove the expired objects into the main thread.
> > >
> > >
> > >
> > > --
> > > 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
> > >
> > >
> > ___
> > 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
>
>
___
osg-users mailing list

Re: [osg-users] Raytracing status

[Michele Bosi]

I am totally not a ray tracing guru, but I would like to have a look
at the code of Adrian to have an idea, where can I find it? Is there
any demo or usable working test of it?

Thanks,
Michele
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Solaris compilation issues in SVN

[Tim Moore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Osfield wrote:
> Hi Andy,
> 
> Yesterday I merged a submission to DatabasePager.cpp that included use
> of various stl alogorithms - such as sort and find and others, the
> submission added a using namespace std, but I don't like importing
> whole namespaces so I removed the code and then added std:: where
> appropriate, clearly I missed a few.  I've just done a search for find
> and sort and added std:: in the appropriate places.  I may have missed
> a few though, could you do a svn update and let me know how you get
> on.

Sorry about that; I sort of knew I was departing from the global OpenSceneGraph 
style,
but I gambled that using namespace std within function bodies would be OK.

Tim

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHX7bHeDhWHdXrDRURAqf9AJ9ns+byxUMg2tuBOZ1W1b7C6dmh7ACeKXLz
SNUuXjVJZvMeW121wZ71DRY=
=83SL
-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] readFontFile possible bug

[Robert Osfield]

Hi Sherman,

On Dec 11, 2007 11:31 PM, sherman wilcox <[EMAIL PROTECTED]> wrote:
> I can still reliably reproduce the multithreaded osgText /
> databasepager crash issue   :)

Could you explain how your recreate the crash, and the circumstances
of the crash.  It may be exactly the same problem as Serge has, but
also just as easily could be another weakness that needs solving.

Aaa you gotta love debugging multi-threaded apps remotely :-)

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Errors when compiling osg development version on VS2005 Vista32 (Release configuration)

[Robert Osfield]

Hi,

This is now fixed, please do a svn update.

Robert.

On Dec 12, 2007 8:54 AM, Роман Григорьев <[EMAIL PROTECTED]> wrote:
> 4>TriStripVisitor.cpp<неи5>C:\Program Files\Microsoft Visual Studio
> 8\VC\include\xtree(1174) : error C3848: expression having type 'const
> osgDB::SharedStateManager::CompareStateAttributes' would lose some
> const-volatile qualifiers in order to call 'bool
> osgDB::SharedStateManager::CompareStateAttributes::operator ()(const
> osg::ref_ptr &,const osg::ref_ptr &)'<неи5>with<неи5>
> [<неи5>T=osg::StateAttribute<неи5>]<неи5>
> C:\Program Files\Microsoft Visual Studio 8\VC\include\xtree(1169) : while
> compiling class template member function 'std::_Tree_nod<_Traits>::_Node
> *std::_Tree<_Traits>::_Lbound(const osg::ref_ptr &) const'<неи5>
> with<неи5>[<неи5>
> _Traits=std::_Tset_traits,osgDB::SharedSta
> teManager::CompareStateAttributes,std::allocator ibute>>,false>,<неи5>T=osg::StateAttribute<неи5>]<неи5>
> C:\Program Files\Microsoft Visual Studio 8\VC\include\set(69) : see
> reference to class template instantiation 'std::_Tree<_Traits>' being
> compiled<неи5>with<неи5>[<неи5>
> _Traits=std::_Tset_traits,osgDB::SharedSta
> teManager::CompareStateAttributes,std::allocator ibute>>,false><неи5>]<неи5>
> C:\repository\osg\include\osgDB/SharedStateManager(88) : see reference to
> class template instantiation 'std::set<_Kty,_Pr>' being compiled<неи5>
> with<неи5>[<неи5>
> _Kty=osg::ref_ptr,<неи5>
> _Pr=osgDB::SharedStateManager::CompareStateAttributes<неи5>]<неи
>
>
> ___
> 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] where to find data/Earth/model.ive

[Wasilios Goutas]

Hi,

I'm new to OpenGL and to oswg.
I downloaded the osg quick start guid and the example code and read 
inside the viewermain.cpp following:
// TBD. Waiting for this file to get a permanent location after
//   the dimain name shuffle. THis is a better example than the
//   cow because it shows off the .net loader.
//viewer.setSceneData( osgDB::readNodeFile(
//"http://www.openscenegraph.org/downloads/data/Earth/model.ive"; 
) );

this path to model.ive does not exist.
Where can I find this earth model?

bye
Wasili


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] sharedstatemanager.cpp win32 release mode compilation error

[Robert Osfield]

Hi Amos & Tim,

I've just checked in the change to use const operators in functors in
SharedStateManager, prompted by email on the same topic from Paul
Martz, this change looks the same as Tim's and is now checked in.

Robert.

On Dec 12, 2007 5:15 AM, Amos Smith <[EMAIL PROTECTED]> wrote:
> With code downloaded via svn this evening (revision 7671), I'm seeing a
> compilation error for osgDB SharedStateManager.cpp in Win32 Release mode.
>
> Excerpt of error description:
>
> C3848: expression having type 'const
> osgDB::SharedStateManager::CompareStateAttributes' would lose some
> const-volatile qualifiers in order to call 'bool
> osgDB::SharedStateManager::CompareStateAttributes::operator ()(const
> osg::ref_ptr &,const osg::ref_ptr &)'
>
>
> Build environment is: WinXP SP2, MS VS 8.1 SP1, using Microsoft Platform SDK
> for Windows Server 2003 R2.
>
>
> Full output for osgDB rebuild follows:
>
> 1>-- Rebuild All started: Project: osgDB, Configuration: Release Win32
> --
> 1>Deleting intermediate and output files for project 'osgDB', configuration
> 'Release|Win32'
> 1>Building Custom Rule E:/OpenSceneGraph/src/osgDB/CMakeLists.txt
> 1>-- searching TIFF -->tiff.h<--><-->E:/3rdparty<--
> 1>-- searching FREETYPE -->ft2build.h<--><-->E:/3rdparty<--
> 1>-- searching JPEG -->jpeglib.h<--><-->E:/3rdparty<--
> 1>-- searching GLUT -->GL/glut.h<--><-->E:/3rdparty<--
> 1>-- searching GIFLIB -->gif_lib.h<--><-->E:/3rdparty<--
> 1>-- searching ZLIB -->zlib.h<--><-->E:/3rdparty<--
> 1>-- searching PNG -->png.h<--><-->E:/3rdparty<--
> 1>-- ERROR: wxWidgets was not found.
> 1>-- Found JPEG: E:/3rdParty/lib/libjpeg.lib
> 1>-- Found PNG: E:/3rdParty/lib/libpng.lib
> 1>-- Configuring done
> 1>-- Generating done
> 1>-- Build files have been written to: E:/OpenSceneGraph
> 1>Compiling...
> 1>WriteFile.cpp
> 1>E:\OpenSceneGraph\include\osgDB/DatabasePager(337) : warning C4800:
> 'osg::Texture::TextureObject *' : forcing value to bool 'true' or 'false'
> (performance warning)
> 1>Version.cpp
> 1>SharedStateManager.cpp
> 1>C:\Program Files\Microsoft Visual Studio 8\VC\include\xtree(1174) : error
> C3848: expression having type 'const
> osgDB::SharedStateManager::CompareStateAttributes' would lose some
> const-volatile qualifiers in order to call 'bool
> osgDB::SharedStateManager::CompareStateAttributes::operator ()(const
> osg::ref_ptr &,const osg::ref_ptr &)'
> 1>with
> 1>[
> 1>T=osg::StateAttribute
> 1>]
> 1>C:\Program Files\Microsoft Visual Studio 8\VC\include\xtree(1169)
> : while compiling class template member function
> 'std::_Tree_nod<_Traits>::_Node *std::_Tree<_Traits>::_Lbound(const
> osg::ref_ptr &) const'
> 1>with
> 1>[
> 1>
> _Traits=std::_Tset_traits,osgDB::SharedStateManager::CompareStateAttributes,std::allocator>,false>,
> 1>T=osg::StateAttribute
> 1>]
> 1>C:\Program Files\Microsoft Visual Studio 8\VC\include\set(69) :
> see reference to class template instantiation 'std::_Tree<_Traits>' being
> compiled
> 1>with
> 1>[
> 1>
> _Traits=std::_Tset_traits,osgDB::SharedStateManager::CompareStateAttributes,std::allocator>,false>
> 1>]
> 1>E:\OpenSceneGraph\include\osgDB/SharedStateManager(88) : see
> reference to class template instantiation 'std::set<_Kty,_Pr>' being
> compiled
> 1>with
> 1>[
> 1>_Kty=osg::ref_ptr,
> 1>_Pr=osgDB::SharedStateManager::CompareStateAttributes
> 1>]
> 1>Registry.cpp
> 1>E:\OpenSceneGraph\include\osgDB/DatabasePager(337) : warning C4800:
> 'osg::Texture::TextureObject *' : forcing value to bool 'true' or 'false'
> (performance warning)
> 1>ReaderWriter.cpp
> 1>E:\OpenSceneGraph\include\osgDB/DatabasePager(337) : warning C4800:
> 'osg::Texture::TextureObject *' : forcing value to bool 'true' or 'false'
> (performance warning)
> 1>ReadFile.cpp
> 1>E:\OpenSceneGraph\include\osgDB/DatabasePager(337) : warning C4800:
> 'osg::Texture::TextureObject *' : forcing value to bool 'true' or 'false'
> (performance warning)
> 1>Output.cpp
> 1>E:\OpenSceneGraph\include\osgDB/DatabasePager(337) : warning C4800:
> 'osg::Texture::TextureObject *' : forcing value to bool 'true' or 'false'
> (performance warning)
> 1>Input.cpp
> 1>E:\OpenSceneGraph\include\osgDB/DatabasePager(337) : warning C4800:
> 'osg::Texture::TextureObject *' : forcing value to bool 'true' or 'false'
> (performance warning)
> 1>ImageOptions.cpp
> 1>FileUtils.cpp
> 1>E:\OpenSceneGraph\include\osgDB/DatabasePager(337) : warning C4800:
> 'osg::Texture::TextureObject *' : forcing value to bool 'true' or 'false'
> (performance warning)
> 1>FileNameUtils.cpp
> 1>E:\OpenSceneGraph\include\osgDB/DatabasePager(337) : warning C4800:
> 'osg::Texture::TextureObject *' : forcing value to bool 'true' or 'false'
> (performance warning)
> 1>FieldReaderIterator.cpp
> 1>FieldReader.cpp
> 1>Field.cpp
> 1>DynamicLibrary.cpp
> 1>E:\OpenSceneGraph\include\osgDB/DatabasePager(337) : warni

Re: [osg-users] Current SVN build failure, VS2005

[Robert Osfield]

Hi Paul,

On Dec 12, 2007 3:19 AM, Paul Martz <[EMAIL PROTECTED]> wrote:
> The output below is from current SVN building osgDB (osg and osgUtil are
> fine).
>
> VS doesn't provide too many clues when xtree or set generate compile errors.
> I haven't dug into this very deeply, but on first glance it appears that
> perhaps CompareStateAttributes::operator() should be declared const?

Looking at the code I think both the CompareStateAttributes and
CompareStateSets operator() methods should be const, I've changed the
code to use const and have rebuilt osgDB just fine, so have gone ahead
and checked it in.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Warning in latest SVN

[Robert Osfield]

Hi J-S, Paul Martz sent the fix into osg-submissions, I merged this
first thing when I booted up my machine this morning, an svn update
will get this fix.

On Dec 12, 2007 2:00 AM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
> Hello Robert,
>
> There is a warning that shows up in the latest SVN in
> include/osg/DatabasePager when compiling on Win32 (VC++2005 Express):
>
> 1>G:\OpenSceneGraph-SVN\OpenSceneGraph\include\osgDB/DatabasePager(337) :
> warning C4800: 'osg::Texture::TextureObject *' : forcing value to bool
> 'true' or 'false' (performance warning)
>
> Replacing this:
>
>  // in bool isCompiled(...)
>  return texture->getTextureObject(contextID);
>
> with this:
>
>  return (texture->getTextureObject(contextID) ? true : false);
>
> fixes it.
>
> Thanks,
>
> J-S
> --
> __
> Jean-Sebastien Guay [EMAIL PROTECTED]
>  http://whitestar02.webhop.org/
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
> ___
> 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] Solaris compilation issues in SVN

[Robert Osfield]

Could you please start a fresh thread when asking questions about a
completely different topic.

On Dec 12, 2007 12:07 AM, Emre Koc <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Does anyone has a C# wrapped or pure C# OBJ loader to use with OSG 2.0 ?
>
> Thanks in advance,
>
> Emre Koch
>
>
>
> ___
> 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] Solaris compilation issues in SVN

[Robert Osfield]

Hi Andy,

Yesterday I merged a submission to DatabasePager.cpp that included use
of various stl alogorithms - such as sort and find and others, the
submission added a using namespace std, but I don't like importing
whole namespaces so I removed the code and then added std:: where
appropriate, clearly I missed a few.  I've just done a search for find
and sort and added std:: in the appropriate places.  I may have missed
a few though, could you do a svn update and let me know how you get
on.

Robert.

On Dec 11, 2007 7:34 PM, Andy Skinner <[EMAIL PROTECTED]> wrote:
> I'm looking for the same kinds of things we've been struggling with in
> the past--standard template library functions that aren't in the solaris
> compiler's headers.
>
> We've fixed them in the past by adding includes to stdlib.h or similar.
> I am looking at a couple in DatabasePager.cpp.  I could try to fix them
> in a similar way, but I notice that there are occurrences of these
> functions with std:: in front of them.  For example, one call to find()
> is std::find(...), and another is just find(...).  The first compiles
> for me, the second doesn't.
>
> At my company, we would address this with the std:: prefix.  But I
> thought we didn't want to do that in the OSG.
>
> Should I address these with std::, as other calls in this file do?  Or
> remove the std:: from the other calls and find the right include to fix
> it?
>
> andy
>
> ___
> 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] image format conversion

[Robert Osfield]

Hi Gerrick,

You could play with using the Texture::setInternalFormat(GLint) method.

Robert.

On Dec 12, 2007 12:07 AM, Gerrick Bivins <[EMAIL PROTECTED]> wrote:
> Hi all,
> I think I know the answer but just in case I'm overlooking something I
> thought I'd ask.
> What is the most efficient way to convert the osg::Image loaded from
> osgDB::readImageFile() to another format, specifically RGBA 32-bit
> floating-point for use
> in a vertex shader? I can do a "brute force" method but if there's a better
> way, I'd go for that.
> biv
> ___
> 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] difference between setThreadSafeRefUnref and setThreadSafeReferenceCounting

[Robert Osfield]

On Dec 12, 2007 12:05 AM, Ulrich Hertlein <[EMAIL PROTECTED]> wrote:
> What might confuse people is that calling:
>
> osg::Referenced* r = new osg::Referenced;
> r->setThreadSafeReferenceCounting(true); // static version
> r->setThreadSafeRefUnref(true); // instance version
>
> do two separate things. The first only sets the default but doesn't enable it
> for the object (which it can't do because it's a static function, just called
> in an unorthodox way). The second actually enables thread-safety for the
> object.
>
> Maybe by renaming the static 'setThreadSafeReferenceCounting' to something 
> like
> 'setGlobalThreadSafeRefUnref' it becomes a little bit clearer?

Possibly a bit clearer, but still open to misleading people, as it
doesn't run through osg::Referenced objects in memory and change them,
it only changes the default setting for newly created osg::Referenced
objects.

There is the pesky issue of backwards compatibility too.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] CameraNode cull masks

[Robert Osfield]

Hi Ben,

On Dec 11, 2007 11:22 PM, Ben Cain <[EMAIL PROTECTED]> wrote:
> Do cull masks work with osg::CameraNode?  The interface is there ... so I'm
> thinking should work.

I'm afraid I couldn't answer this without download OSG-1.2 and
reviewing and testing the code...

> Note this particular application is using OSG 1.2.  I'm thinking of bringing
> it up-to-date ... using latest, non-Producer version.

Are a just dip your toe in the water why not just updated to 2.x and
use the external osgProducer, this should ease the porting task.

Porting from osgProducer to osgViewer can be as easy as just changing
a few lines of code to many hundreds, it all depends on how much of
your code directly uses Producer/osgProducer.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgvolumed usage

[Robert Osfield]

Does you source data have alpha values in it

On Dec 11, 2007 9:07 PM, R. Aditya Kadambi <[EMAIL PROTECTED]> wrote:
> I am trying to use it like this now. But I can't find a way to set alpha
> value from the help menu.
>
> $ ./osgvolumed --images file.1png file2.png
>
> I don't see a volume stack. Any suggestions?
>
> Thanks.
>
>
>
> On Dec 11, 2007 9:40 AM, R. Aditya Kadambi <[EMAIL PROTECTED]> wrote:
> > Hi Robert;
> >
> > Thanks. So, would this usage be valid:
> >
> > $ osgvolumed --images *.png --alpha 
> >
> > Thanks,
> >
> >
> >
> >
> >
> > On Dec 11, 2007 2:04 AM, Robert Osfield < [EMAIL PROTECTED]> wrote:
> >
> > > HI Aditya,
> > >
> > > You need to use data with a alpha value, or intensity data otherwise
> > > you'll just end up with a solid block.
> > >
> > > Robert.
> > >
> > >
> > >
> > >
> > > On Dec 11, 2007 3:30 AM, R. Aditya Kadambi <[EMAIL PROTECTED]> wrote:
> > > > I am trying to use the "osgvolumed" from the examples program. I am
> looking
> > > > for sample data to use it (2d or 3d).
> > > >
> > > > If I wish to use a stack of 2d images, the help menu says, I need to
> do
> > > > this:
> > > >
> > > > $osgvolumed --images 
> > > >
> > > > I tried to use stack of *.png or *.rgb images and don't see the volume
> > > > construction. Can someone point me to sample data and the data type to
> be
> > > > used for this program. Also, what are the
> > > > 3d image formats I can use.
> > > >
> > > > Thanks,
> > > >
> > > > ___
> > > > 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] Obtaining the contextID

[Robert Osfield]

Hi Paul,

The contextID is stored in the osg::State, SceneView has a State and
therefore the ContextID.  The osg::Camera without any graphics context
doesn't though as its through the GraphicsContext that it gets its
State.

Workarounds for you would be to create a dummy GraphicsContext for
each window that the apps opens and make this GraphicsContext share
the SceneView's State.  Alternatively you could have a hack where you
register a callback to get the contextID given a Camera, then an
application specific custom callback could implement a mapping between
the Camera and the appropriate SceneView and then finally to the
ContextID.

Robert.

On Dec 11, 2007 7:18 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
>
>
> Hi Robert -- I'm working with an older app that deals directly with
> SceneView. It effectively creates its own window and manages its own
> graphics contexts.
>
> I've found this app doesn't work with osgOQ. osgOQ uses a Camera post draw
> callback to retrieve the query results, and therefore needs the abstract
> unsigned int contextID. To get this, it uses the following code:
> camera.getGraphicsContext()->getState()->getContextID().
>
> The only problem is that the app never set up a GraphicsContext on the
> SceneView's Camera. SceneView doesn't do this itself (of course -- it's
> ignorant of contexts).
>
> Note that osgOQ can get the contextID just fine in other parts of the code,
> such as in a CullVisitor traverse() call, or in a draw callback or
> drawImplementation(). The contextID is readily available from
> RenderInfo::getState(). It's just the Camera post draw callback that is the
> problem, because I must go through the Camera's (non-existent)
> GraphicsContext to get State.
>
> It seems like, somewhere, there should be a mapping of actual platform
> rendering context IDs to OSG's abstract unsigned int contextID, such that,
> if a context is actually current, code should be able to look up the
> abstract unsigned int contextID in a map somewhere. I've been unable to
> locate any such construct in OSG.
>
> I'm certain you'll recommend porting to osgViewer, but telling my client
> that the previously-supported OSG interface they coded to is incompatible
> with osgOQ isn't really an option. So, if there's no way for me to get a
> contextID from a Camera that doesn't have a GraphicsContext, then I'll have
> to look into alternate implementations for osgOQ.
>
> Paul Martz
> Skew Matrix Software LLC
> http://www.skew-matrix.com
> 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] readFontFile possible bug

[Serge Lages]

Hi Robert,

On Dec 11, 2007 8:59 PM, Robert Osfield <[EMAIL PROTECTED]> wrote:

> Hi Serge,
>
> How reliably can you recreate the crash?
>
> Does it happen with osgviewer or other OSG examples?
>
> Could you explain whats happening in your app before the crash.
>


Here is the context of the crash :

DatabasePager configuration :
pager->setExpiryDelay(5);
pager->setUnrefImageDataAfterApplyPolicy(true, true);
pager->setDeleteRemovedSubgraphsInDatabaseThread(false);
pager->setMaximumNumOfRemovedChildPagedLODs(50);
pager->setMinimumNumOfInactivePagedLODs(0);

Registry configuration :
osgDB::Registry::instance()->getOptions()->setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL);

To make it crash, I have a custom manipulator which randomely move into a
very high paged database (lots of giga). The database contains nodes with
simple geometries but also texts. Sometime it crashs after hours of
randomely moves, sometime after just 1 or 2 minutes. The crash happens in
two locations :

1 - into osgText::Text::setFont (Text.cpp line 119) because the variable
"font" is a corrupted pointer.
2 - into databasepager.cpp (line 604), during the initialization of
databaseRequest->_loadedModel, because the pointer returned by readNodeFile
is corrupted.

These crashs happen into the pager thread, and the main thread is always
into the removeExpiredSubgraphs method at this moment. In both cases, we
have a very short laps of time where a C pointer is used for an object
instead of a ref_ptr.

For the crash number 2, it seems that switching readNodeFile by a readNode
fix it. But I think that the better solution will be to prevent any cache
clear during the readNodeFile call into databasepager.cpp, I will
investigate further this morning and see if I can fix it.


>
> If we can work out the conditions that the crash happens we'll have a
> much better chance of isolation. It could be as your describe an
> object be deleted just when another thread is about to take a ref to
> it, I would have thought this would be a pretty rare condition though.
>
> Robert.
>
> On Dec 11, 2007 3:55 PM, Serge Lages <[EMAIL PROTECTED]> wrote:
> > I have another theory about the crash, let's say that :
> >
> >
> > osg::Object* object = osgDB::readObjectFile(foundFile, userOptions ?
> > userOptions : localOptions.get());
> >
> > read the object from the cache, and between this moment and the one
> where
> > the font object is set to a ref_ptr into setFont, the cache is cleared
> (into
> > another thread). With this scenario the pointer points to a deleted
> object
> > or is there anything to prevent it ?
> >
> > In my case this scenario is possible as I load my IVE with the
> databasepager
> > and that I remove the expired objects into the main thread.
> >
> >
> >
> > --
> > 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
> >
> >
> ___
> 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

[osg-users] Errors when compiling osg development version on VS2005 Vista32 (Release configuration)

[Роман Григорьев]

4>TriStripVisitor.cpp<неи5>C:\Program Files\Microsoft Visual Studio
8\VC\include\xtree(1174) : error C3848: expression having type 'const
osgDB::SharedStateManager::CompareStateAttributes' would lose some
const-volatile qualifiers in order to call 'bool
osgDB::SharedStateManager::CompareStateAttributes::operator ()(const
osg::ref_ptr &,const osg::ref_ptr &)'<неи5>with<неи5>
[<неи5>T=osg::StateAttribute<неи5>]<неи5>
C:\Program Files\Microsoft Visual Studio 8\VC\include\xtree(1169) : while
compiling class template member function 'std::_Tree_nod<_Traits>::_Node
*std::_Tree<_Traits>::_Lbound(const osg::ref_ptr &) const'<неи5>
with<неи5>[<неи5>
_Traits=std::_Tset_traits,osgDB::SharedSta
teManager::CompareStateAttributes,std::allocator>,false>,<неи5>T=osg::StateAttribute<неи5>]<неи5>
C:\Program Files\Microsoft Visual Studio 8\VC\include\set(69) : see
reference to class template instantiation 'std::_Tree<_Traits>' being
compiled<неи5>with<неи5>[<неи5>
_Traits=std::_Tset_traits,osgDB::SharedSta
teManager::CompareStateAttributes,std::allocator>,false><неи5>]<неи5>
C:\repository\osg\include\osgDB/SharedStateManager(88) : see reference to
class template instantiation 'std::set<_Kty,_Pr>' being compiled<неи5>
with<неи5>[<неи5>
_Kty=osg::ref_ptr,<неи5>
_Pr=osgDB::SharedStateManager::CompareStateAttributes<неи5>]<неи


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org