version of OpenSceneGraph in this part of our cycle, but I
may be able to make a change. I think I feel better with the change to clear
the existing list element in ~GLException. But I think the other approach
would be better for current OSG.
andy
-Original Message-----
From: Andy Ski
this refactor perhaps these data structures could be reset within the
GLExtensions destructor.
I don't have time to look into a fix right now, so either dive into the code
yourself or avoid creating and destructor lots of contexts.
Robert.
Robert.
On Wed, 19 Sep 2018 at 15:52, Andy Skin
reuse it
will provide better performance.
Cheers,
Robert.
On Mon, 17 Sep 2018 at 19:08, Andy Skinner wrote:
>
> If we get our contextIDs from GraphicsContext::createNewContextID(), it could
> give us a new number or return a previous one, if we are returning them with
> GraphicsCon
up the GLExtensions object in 3.4
onwards (I haven't checked further back)
For graphics performance I would recommend that applications don't go creating
and destroying GraphicsWindows, if possible just hide the window and reuse it
will provide better performance.
Cheers,
Robert.
On
If we get our contextIDs from GraphicsContext::createNewContextID(), it could
give us a new number or return a previous one, if we are returning them with
GraphicsContext::decrementContextIDUsageCount. Right?
Is there an intended connection between a contextID that has been used and a
new one?
So, to be clear, we'll leave it as is?
thanks
andy
Needing to put a using in lots of places across the OSG to just quieten
inappropriate warnings is pretty crappy. The more superfluous code you have in
your code base the less easy it is to read, the easier it to break. This makes
me very wa
s] ShaderComposer::releaseGLObjects warning
Hi Andy,
On 26 April 2016 at 20:31, Andy Skinner
mailto:andy.skin...@mathworks.com>> wrote:
Thanks for that fix. There is a remaining issue, and I'm not sure if you would
see it as a bug or a dodgy compiler warning. :)
We get a sim
Thanks for that fix. There is a remaining issue, and I'm not sure if you would
see it as a bug or a dodgy compiler warning. :)
We get a similar message about osgUtil::CullVisitor::clone().
NodeVisitor uses META_Object, which brings in:
virtual osg::Object* clone(const osg::CopyOp& copyop) cons
We are getting a warning for ShaderComposer::releaseGLObjects:
'void osg::ShaderComposer::releaseGLObjects(osg::State *)' : member function
does not override any base class virtual member function
osg::Object::releaseGLObjects is virtual, but
osg::ShaderComposer::releaseGLObjects is not. Is the
ight need to be updated. I think, from reading, that if I installed compiler
command tools I'd get the headers folder in the framework, and maybe then CMake
would find it again.
andy
From: Andy Skinner
Sent: Tuesday, January 28, 2014 5:16 PM
To: OpenSceneGraph Users (osg-users@lists.opensce
We're using 3.0.1. I'd like to update, but at the moment don't have time and
have something else going on.
I'm able to build on a Mac OS X 10.7.5 machine. With a few changes to our
makefile (which calls cmake and then gmake), I'm trying to build on Mac OS X
10.8. (The changes involve specify
We've seen that we have calls to glViewport(800, 600), mixed in with calls to
the actual size of our viewport.
Is the final state.apply() call at the end of RenderStage::drawImplementation()
intended to set things back to a default state after rendering everything?
I've seen that RenderStage h
Thanks for comments, Peter.
By "easier to pick", I didn't mean relative to other lines in the scene, but
that I wouldn't have to be as close to the actual line geometry. It is a
question of whether the line will be in the list of intersections, rather than
which intersection I choose.
I suspe
I know that intersections are about 3d world coordinates, and line widths are
about pixels. But is there a way to use line widths in calculating
intersections with the polytope intersector?
In other words, I want a wider line to be easier to pick.
I could just expand the polytope a bit, except
Should we expect the picking Intersectors to look at the clipping planes set up
by ClipNodes and Scissors? We can clip the results, but it seems like the sort
of thing the Intersectors would be good at.
Basically, we've been getting points picked that should have been clipped by a
clip box. T
Thanks, Ulrich. Sorry, I missed your reply before.
Yes, your results do sound different. I'd expect no argument to have green
dots instead of green discs, because the point size won't be set. They're
small and right on the edge of the triangle.
And in our case, the red triangle and the line
Attached is a simple OSG example that, on Mac with nVidia card, seems to show
point geometry with the Point StateAttribute set causing other geometry to be
clipped. We did not see this on a Mac with an ATI card. This has been
reproduced on the OSG trunk, but has been seen on older versions as
We're just moving from 2.8.something to 3.0.1. Looks like I should update from
using .osg to .osgx.
While I was looking at that, I was wondering about this line from
DogOSGWrapper.cpp:
if
(osgDB::Registry::instance()->loadLibrary(*itr)==osgDB::Registry::LOADED)
return writeObject(obj,fw)
Maybe far off, but something I've seen:
Do you happen to be working on a mac? We've seen something on one particular
graphics card on the mac, where drawing with points sometimes seems to affect
clipping on other objects. It seems really weird.
I think that when we didn't set the osg::Point s
This will sound like a reach, and I can't easily make a simple case to show it.
But I'd like to know if this rings a bell with anyone.
We've seen geometry disappear when in the same scene as a point, on NVidia 7300
on a Mac.
If I comment out the part of our code where we set the Point StateAtt
Sometimes our scene only consists of lines. When we use
COMPUTE_NEAR_FAR_USING_PRIMITIVES, the near and far aren't computed correctly,
because the TriangleFunctor used with ComputeNearestPointFunctor doesn't look
at points or lines.
In order to get this to work, if I want to consider lines the
cember 06, 2010 9:46 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] plugin source code
>
> Hi Andy,
>
> The deprecated DotOsgWrappers can now be found in
> src/osgWrappers/deprecated-dotosg/*/*.
>
> Robert.
>
> On Mon, Dec 6, 2010 at 2:34 PM, Andy Skinner
> wrot
I was looking at submitting a fix for the osg plugin. We use shared arrays
(see osgsharedarray example) in the last stable release of OSG. We had a
problem writing osg files of our scene because of a static cast in the osg
plugin. It assumed it knew what the array was (FloatArray, for example
I'm not sure why the calculations done in AutoTransform are done in the cull
traversal, rather than in update.
I'd have thought that update was for objects setting things in themselves, and
the cull was read only.
Does the update not accumulate transform matrices? Something else?
thanks
andy
> GraphicsWindowEmbbedded usage assume that context is always current
> for the life of the viewer. With a bit of hacking you could probably
> disable the clean up the view and graphics window are attempting to
> do, but it would probably be far easier to remove the destroy the
> graphics window/v
I'm using OSG 2.8.3, the last stable release.
I'm using a Viewer with GraphicsWindowEmbedded.
On closing the window, the Viewer is destroyed, and the destructor tries to
close the GraphicsContext. Inside flushAllDeletedGLObjects,
flushDeletedGlPrograms is called. Inside that, there is a call
What is the difference between the cull callback set on a Drawable and a
NodeCallback set as a cull callback on a Node?
I saw one thread on the list where someone was confusing them, and the
difference was mentioned, but not spelled out. It appears the
Drawable::CullCallback is used to decide
I was able to build from the updated 2.8 branch last night. This morning I was
able to telnet to a mac and run osgconv without complaints about not being able
to get to the display. That was the case we were testing before.
thanks
andy
> -Original Message-
> From: osg-users-boun...@li
1:00 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] 2.8.3 testing
>
> Andy and Paul -
>
> I submitted a fix for this (r10927) which reorders some of the ifdef
> checking so that it works properly under OSX.
>
> Chuck
>
> On Mar 22, 2010, at 9
I just got OpenSceneGraph-2.8, and tried to build on OS X.
I'm getting an error in OpenThreads/Atomic, complaining that int32_t does not
name a type.
I'm following the unix instructions, doing configure and then make.
I had just build the trunk (at least the first part) and got past this.
Have
Of Paul Martz
> Sent: Monday, March 22, 2010 11:35 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] 2.8.3 release likely, need community
> assistance
>
> Andy Skinner wrote:
> > I'm building the trunk again now on OS X, to see if Robert has fixed
> the probl
I'm building the trunk again now on OS X, to see if Robert has fixed the
problem you mention. If he has, maybe you could bring this change back in.
andy
> Rats. I think some more changes were made after I tested this off of
> the trunk.
>
> I don't mind taking a look at it, but haven't been p
Rats. I think some more changes were made after I tested this off of the trunk.
I don't mind taking a look at it, but haven't been paying attention to how much
time I'd have to get this fixed. How long? Of course, if it is breaking the
trunk's build, I assume it will be fixed soon.
Thanks fo
Paul,
Robert was at one time (Novemeber, December) working with removing some more
static initializers. We really need to get up to date on OSG, and we need to
get rid of the initializers. If Robert was able to complete that (he hadn't
had time as of December), it would be a big help. (We wa
I'd like to see the SceneGraphOrderRenderBin implementation if it could fit in.
It was discussed in May.
andy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Saturday, June 20, 200
-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Andy Skinner
Sent: Tuesday, May 19, 2009 10:27 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenSceneGraph-2.8.1 release candidate five tagged
Windows XP with NVidia car
Windows XP with NVidia card has been fine so far. I'm using cmake 2.6 patch 2.
I'm working on OSX 32 and 64 bit, and linux 64 bit.
andy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Se
I'll try, but not sure I can finish this afternoon. I was still working on rc
4.
andy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Monday, May 18, 2009 12:20 PM
To: OpenSceneGra
How much feedback do you need for OSG 2.8.1?
thanks,
andy
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
RC3 seems OK to me on Win32, linux 64, and Intel mac 32.
thanks,
andy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Thursday, April 23, 2009 10:41 AM
To: OpenSceneGraph Users
Subje
Thanks. Sorry I'm slow--I have built rc2 on Intel Mac, win32, and Linux 64. I
have tried it in my app on win32. I guess instead of trying what I have on the
other platforms, I should get the new one. I've had a lot going on, so haven't
been able to give quick responses.
andy
-Original
009 12:39 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG 2.8.1
Hi Andy,
2009/3/18 Andy Skinner
mailto:andy.skin...@mathworks.com>>
You know, I was thinking that using SVN was going to get me the latest, but I
bet I'm just getting SVN from when 2.8.0 was made. I'm using the li
ehalf Of Robert Osfield
Sent: Wednesday, March 18, 2009 11:05 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG 2.8.1
HI Andy,
2009/3/18 Andy Skinner
mailto:andy.skin...@mathworks.com>>
I've built the OSG successfully, but it is going to take me longer to test it
with our softwa
I've built the OSG successfully, but it is going to take me longer to test it
with our software.
Last time I just built it without updating with our code, and now I'm finding
that I have to change some of our BoundingSphere code that doesn't compile.
I'll give feedback on the 2.8.1 as soon as
I definitely want to give the 2.8.0 trunk a try, and will try to do it in
relatively soon. It might be next week.
andy
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
I've not heard from Blasius Czink yet, but I have found out that there is a
/usr/include/sys/atomic.h that declares things like atomic_or_uint_nv(), but
does not declare atomic_xor_uint_nv(). Maybe the xor operation could be
removed instead of the whole thing. I can't find any reference to xor
Thanks. I've sent an email to Blasius (hoping I got the email from Gmane
correctly), and will see if he has a suggestion.
andy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Wedne
cenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Andy Skinner
Sent: Tuesday, January 06, 2009 1:45 PM
To: OpenSceneGraph Users
Subject: [osg-users] atomic_xor_uint_nv on Solaris
I'm trying to build a recent SVN version, and get errors for
include/OpenThreads/Atomic:
I'm trying to build a recent SVN version, and get errors for
include/OpenThreads/Atomic:
line 183: Error, badfunccp: The function "atomic_xor_uint_nv" must have a
prototype.
I'm not sure about this one. How is that supposed to be defined?
line 243: Error, badargtype2: Formal argument 2 of
an ignore scale orientation and multiply scale,
rotation, and translation, and get the original.
I don't really understand scale orientation.
andy
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner
Sent: Thursday, October 09, 2008 2:33 PM
To:
Actually, looks like I can ignore scale orientation and multiply scale,
rotation, and translation, and get the original.
I don't really understand scale orientation.
andy
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner
Sent: Thu
__
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner
Sent: Thursday, October 09, 2008 2:27 PM
To: OpenSceneGraph Users
Subject: [osg-users] reconstructing a decomposed matrix
I'd like to make sure I understand something I'm doing. I'm calling
decompose()
I'd like to make sure I understand something I'm doing. I'm calling
decompose() on a modelview matrix. I get a translation vector, rotation
quaternion, scale vector, and scale orientation quaternion.
How do I put them back together to get the original matrix? As I said, I'm
trying to check m
I'm not, but I'm pushing and popping the matrices. I didn't think I was
changing anything else.
andy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz
Sent: Thursday, August 28, 2008 11:11 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users]
Robert, I've got a drawImplementation() method that gets the projection and
modelview matrices and does something with them, pushes both matrices and sets
up pixel coordinates (glOrtho in projection, glLoadIdentity in modelview),
calls osg::Geometry::drawImplementation(), and then does the pops
This method returns an unsigned int. It calls size() on the vector, which
returns size_type.
In our builds of software using OSG, we're getting warnings about a conversion
of a 64 bit value to unsigned int.
Has the OSG project had to change the type of common methods like this? Does
it go we
Actually, I think you should always go away on vacation as you're about to make
a release. :) I would be more comfortable with a little time to let the dust
settle than what is usually given.
andy
___
osg-users mailing list
osg-users@lists.openscene
I'd like to know more about the AutoTransform auto-scale implementation. We
want something similar, but we think we need to account for non-uniform scaling.
Could I get a description of CullingSet::computePixelSizeVector()? I see it
was written in 2002, but I'd appreciate any help in understan
dylib"
to LDFLAGS and that seemed to work. I do this in a Makefile project and
use the resulting dylib in a larger XCode project. Then i didn't have
to do the install_name_tool voodoo.
Martins
Andy Skinner wrote:
> Thanks, but that's what I'm trying to avoid. Don't
name_tool -id ..."
in a script as a Run Script Build phase. I don't know if you can do it
in XCode directly. Seems to work. Let me know if you need more info
and I'll dig up the exact script.
Martins
Andy Skinner wrote:
> I'll admit to being a little past the limit of
of the near/far distances for
objects in the scene is in some way messed up.
Is it possible to recreate this warning with osgviewer when loading
one of your models?
Robert.
On Wed, May 21, 2008 at 5:04 PM, Andy Skinner
<[EMAIL PROTECTED]> wrote:
> There is an osg::notify at osg::WARN
There is an osg::notify at osg::WARN level in the CullVisitor in
updateCalculatedNearFar(matrix, drawable, isBillboard).
There are several, actually, but I'm asking about this one:
if (d_near<0.0) osg::notify(osg::WARN)<<"2) sett near with
d_near="<___
all seems well.
thanks
andy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: Wednesday, May 21, 2008 8:37 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Projection vs Camera
Hi Andy,
On Wed, May 21, 2008 at 1:11 PM, Andy Skinner
&l
I found a dusty part of our code where we have a Projection and a Camera. I've
found an old email (2006) from this list about how the Projection is deprecated
in favor of the Camera. I just wanted to check-is this correct? If we've got
a Camera, we don't need a Projection?
thanks
andy
_
Hmmm. I found an email message from a long time ago with me asking and Robert
saying they should be the same. He was guessing that it was vis studio making
them lower case. But I can't find anything else about it (I'm sure we talked
about this at some point, but I haven't found a case-sensiti
Hi. Our windows plugin directory used to be named osgplugins-.
Now they seem to be osgPlugins-.
Anyone familiar with this change? I know that windows doesn't care about case,
but we have all kinds of systems here, and I'm not sure we don't have a script
that runs on a different platform to c
lease test SVN of OpenSceneGraph
On Thu, Apr 24, 2008 at 5:12 PM, Andy Skinner
<[EMAIL PROTECTED]> wrote:
> The latest SVN reports version 2.3.11, and builds on our solaris, mac,
> win32, and linux 64 systems.
Thanks for the feedback Andy, its good to hear things working.
What ver
The latest SVN reports version 2.3.11, and builds on our solaris, mac,
win32, and linux 64 systems.
andy
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
I recently tested 2.3.9 in our software, and although I haven't been
able to give it a thorough testing, it does work. I'm currently
building SVN (downloaded this morning after your request) on windows, 64
bit linux, solaris, and mac. (We use cmake on everything.)
I'll let you know when it is do
lto:[EMAIL PROTECTED] On Behalf Of Andy
Skinner
Sent: Friday, April 18, 2008 11:08 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Please test SVN of OpenSceneGraph in
prefor2.3.9devrelease
On all three platforms on which I compiled, I got an error:
FrameBufferObject:619: error: 'COLOR_BUFFER15&#
On all three platforms on which I compiled, I got an error:
FrameBufferObject:619: error: 'COLOR_BUFFER15' is not a member of
'osg::Camera'.
I just did "svn update" in my root directory before compiling. Should
I have done something else?
andy
-Original Message-
From: [EMAIL PROTECTED]
Andy et. al,
On Thu, Apr 17, 2008 at 6:24 PM, Andy Skinner
<[EMAIL PROTECTED]> wrote:
> It built for me in windows and linux 64 bit. I'm still trying to get
a
> solaris machine, and that is often where there has been trouble.
Thanks for the testing. I'll leave tagging 2.3.9 t
It built for me in windows and linux 64 bit. I'm still trying to get a
solaris machine, and that is often where there has been trouble.
andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Thursday, April 17, 2008 10:45 AM
To: OpenSc
I'm trying to understand how to use AutoTransform to make an object that
keeps its rotation and scale the same as I transform the scene or change
the size of the window.
The rotation part seems fine, but I've had some problem with the scale.
I set AutoScaleToScreen to true and apply a scale for th
So far, my windows and OSX compilations have been fine.
The Solaris compilation failed on
OpenFlight/LightSourcePaletteManager.cpp, needing an include for the
sprintf call. Adding #include to the list of #includes in that
file works fine. I'm up to about 85% now.
andy
-Original Message---
Oh, and I haven't had time to explore the Solaris OpenGL macros we
discussed. I've got 2.3.6 compiled with and without them, including
examples, but haven't been able to explore them yet.
andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfiel
Sorry, just getting to it. I can do all those you mention, but give me
some time.
andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Monday, March 31, 2008 6:53 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Testing of OSG an
issions as appropriate.
It's one thing for a developer to decide to use macro wrappers in
their end application, but portable middleware libraries like OSG must
avoid such trickery.
cheers
-- mew
On Fri, Mar 21, 2008 at 7:12 AM, Andy Skinner
<[EMAIL PROTECTED]> wrote:
> Thanks,
Thanks, Mike, for putting it in this perspective. Now that you mention
it, we agree that this would break things that we use.
This raises an issue found recently as we were building OSG on Solaris.
On our Solaris machines, /usr/include/GL/gl.h has, near the bottom, a
bit of code like:
#ifndef SUN
9:44 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Testing of SVN version please
Hi Andy,
On Fri, Mar 14, 2008 at 1:30 PM, Andy Skinner
<[EMAIL PROTECTED]> wrote:
> I've just seen a compile error in osgviewerWX.cpp on OSX, complaining
> that cout is not a member of std. I'll
I've just seen a compile error in osgviewerWX.cpp on OSX, complaining
that cout is not a member of std. I'll get back to you about it as soon
as I can.
andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Friday, March 14, 2008 8:34
I'm compiling on OSX right now, too, if you want to hold off for a bit.
andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Friday, March 14, 2008 7:12 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Testing of SVN version pleas
t I'll go do a dev release tomorrow morning.
Cheers,
Robert.
On Thu, Mar 13, 2008 at 6:42 PM, Andy Skinner
<[EMAIL PROTECTED]> wrote:
> It seems that there is a SUN_OGL_NO_VERTEX_MACROS define that I should
> set. If I google that, I get a lot of source references, and a few
>
I've also had a problem with an include needed.
include/osgViewer/api/X11/GraphicsWindowX11 has a call to memset() in
it. It needs #include in it before that. I put it up near
the other includes higher in the file.
This is from defining that Sun define and continuing. I've not yet
tried your
Osfield
Sent: Thursday, March 13, 2008 2:34 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Testing of SVN version please
On Thu, Mar 13, 2008 at 6:15 PM, Andy Skinner
<[EMAIL PROTECTED]> wrote:
> I built SceneGraphBuilder.i to get a look at the preprocessed code.
> This looks like:
&
of code is perfectly valid so I can only guess that the Sun
gl.h used a wacky #define for glColor4f that is polluting the names
space. Could you try tweaking the names so they don't conflict with
OpenGL. Removing the gl would be fine.
Robert.
On Thu, Mar 13, 2008 at 5:53 PM, Andy Sk
I hit a problem compiling on solaris.
I've attached a part of the output. I don't see what it wrong. It says
line 61 of the header file SceneGraphBuilder has an error:
line 61: Error, norparerr: ")" expected instead of "->"
and line 61 looks like:
void glColor4f(GLfloat red, GLfloat green, GL
I didn't see the original post here, but I'm downloading SVN now.
I'll try to build on solaris, windows, and linux. But it will take me a bit to
get it set up to build under our environments, so hang on a bit.
thanks
andy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTEC
Thanks!
Hopefully Robert can give it a look when he gets back.
thanks,
andy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien
Guay
Sent: Tuesday, February 12, 2008 9:21 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] intersect() method
J-S, did you get to do any timing with my proposed use of doubles in the
intersection code?
Thanks,
andy
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
I've submitted a change to the submission list. Please take a look and tell me
if and how much it affects timing.
thanks
andy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien
Guay
Sent: Wednesday, February 06, 2008 11:11 AM
To: OpenSceneG
In your work, could you give me an idea of how often you intersect with a
particular line segment object? I'm trying to decide if it is worth it to keep
a Vec3d in the class (marking whether it is valid), or keeping double versions
of _s and _e.
thanks,
andy
-Original Message-
From:
d.
I think I'll submit a version of LineSegment, and you (Robert and the
mailing list) can tell me what you think.
andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy
Skinner
Sent: Tuesday, February 05, 2008 8:57 AM
To: OpenSceneGraph Users
I'm not sure what changed (in OSG or our code), but one of our unittests
is failing on Windows as I try to upgrade our software to OSG 2.3.3.
The picking I'm doing isn't hitting anything. It appears that the use
of floats in the LineSegment::intersect(BoundingSphere) method may be
hurting us.
I'v
Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
Hi Andy,
On Jan 22, 2008 8:31 PM, Andy Skinner <[EMAIL PROTECTED]>
wrote:
> I'm sure I've asked this before, and if there's an answer, sorry.
I'll
> try to remember. :)
>
> Should the OpenThreads l
I'm sure I've asked this before, and if there's an answer, sorry. I'll
try to remember. :)
Should the OpenThreads library version increment to keep track of the
OSG one, even when the OpenThreads library hasn't changed?
The 2.3.3 one is libOpenThreads.so.2.2.0.
andy
__
ECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Tuesday, January 15, 2008 9:43 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
On Jan 15, 2008 2:37 PM, Andy Skinner <[EMAIL PROTECTED]>
wrote:
> I wonder whether something got merg
w-matrix.com
303 859 9466
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Andy Skinner
> Sent: Tuesday, January 15, 2008 7:37 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
>
&g
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph
-2.3.2/include/osg/OcclusionQueryNode
This is for the 2.3.2, so it looks to me like you have an out of date
version of OcclusionQueryNode for some reason.
Robert.
On Jan 15, 2008 1:42 PM, Andy Skinner <[EMAIL PROTECTED]>
wrote:
>
field
Sent: Tuesday, January 15, 2008 4:08 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
Hi Andy,
On Jan 14, 2008 8:12 PM, Andy Skinner <[EMAIL PROTECTED]>
wrote:
> I'm having trouble compiling. (Sorry if this has been discussed and I
> missed
1 - 100 of 195 matches
Mail list logo
