Hi,
I was the creator of the 3rd party dependancies package you downloaded (I
should add that info to the wiki).
When I started using VS2010 with OSG no binaries where available for the 3rd
party libraries so I had to build them all myself. After doing so I made them
available for others to eas
Thanks for all these clarifications !
Is it the same mechanism for StateAttribute ?
For example, if I create a subclass "MyTexture" of osg::Texture, will
compileGLObjects/releaseGLObjects methods of "MyTexture" be automatically
called when needed ?
> If you subgraphs aren't attached to the vi
Hi, Preet,
Robert is probably offline now, so I'll attempt to pick up where he left
off...
On 02/14/2012 12:47 PM, Preet wrote:
I didn't understand what was meant by local origin here. Let's say I
have a model of the Sphinx I want to show on the surface of the Earth
(coincidentally I'm tryi
Hey Robert,
Thanks for the detailed response. I had a few follow up questions.
On Tue, Feb 14, 2012 at 7:39 AM, Robert Osfield
wrote:
> Hi Preet,
>
> Rui was a little cryptic is his explanation so I'll expand on it
> further. What you are seeing is numerical precisions issues down on
> the grap
Will do with the logs, thanks.
I thought about the debugging trick but I don't have a debug build to walk
through. I suppose I'll go ahead and build one and get it working since I see
so many needs for this technique
Thanks,
Paul
--
Read this topic online here:
http://forum.ope
HI Aurelien,
On 14 February 2012 11:09, Aurelien Albert wrote:
> I found a workaround :
>
> 1/ In MyGeometry::drawImplementation :
> => check if objects are compiled for this context, if not, call
> "compileGLObjects"
compileGLObjects() is only called during the compile traversals done
after vi
Hi Vincent,
On 14 February 2012 08:25, Vincent Bourdier wrote:
> Just a few word to conclude this issue : I had to swap the BGR to RGB colors
> by myselt, the following code was not enougth to make it :
This suggest you are doing something wrong with your setup of your
image. The internal textu
Hi Clement,
It could be a driver issue. It could be something else going. I
really can't tell. I know way too little about the specifics of your
setup. Hows about posting your data somewhere so that others can look
at it. Also do the problems exist with osgvolume?
Robert.
On 14 February 2012
Hi Preet,
Rui was a little cryptic is his explanation so I'll expand on it
further. What you are seeing is numerical precisions issues down on
the graphics card as internally the graphics card uses floats for
vertices and floats for the modelview matrix.
The solution to this problem is make sure
Hi Paul,
There isn't any way I pinpoint what the problem is from the details
provided. I general I would say it would say that you seem to be
doing the things correctly that you've listed, but since there is so
much left open ended I can't say more than this.
One thing you can do to start to wor
I found a workaround :
1/ In MyGeometry::drawImplementation :
=> check if objects are compiled for this context, if not, call
"compileGLObjects"
2/ In MyGeometry::~MyGeometry :
=> call releaseGLObjects(NULL)
But I'm surprised that I have to do this "by hands".. did I miss something ?
-
Marius Kintel writes:
> On Feb 13, 2012, at 11:41 AM, Philipp Moeller wrote:
>
>> I ran into a strange problem with osgQt, where setting the
>> contextMenuPolicy to Qt::CustomContextMenu for a GLWidget and spawning a
>> QMenu from a slot that is connected to the event breaks the event
>> handling
Hi all,
Just a few word to conclude this issue : I had to swap the BGR to RGB
colors by myselt, the following code was not enougth to make it :
I would naively expect that either
_image->setImage(width, height, 1, GL_RGB,
GL_RGB, GL_UNSIGNED_BYTE, data, osg::Image::NO_DELETE);
or
13 matches
Mail list logo
