David Glenn writes:
Chriss10 wrote:
I added eventhandler, but it doesn't work for me!
It does not matter how many times I pess 'f', my application will only be
shown on one screen.
Can somebody help?
Other ideas? I think it should be possible to span it over 2 fullscreens.
Well I'll
Hi Don,
Ok, than you can try disabling depth writes while rendering your point
sprites. You can use osg::Depth attribute to disable depth writes. For
example:
_state-setAttribute(new osg::Depth(osg::Depth::LESS, 0.0, 1.0, false));
The last parameter in constructor of osg::Depth controls depth
Hi Sean,
I haven't seen any perfomance slow downs with VBO usage. I've been
testing the VBO side pretty heavily over the last week, using paged
databases that use VBO's.
A VBO vertex array of size 65535 is not particularly large at all and
shouldn't present any issues. Are you dynamically
Hi John, Steve, et. al,
On Tue, Dec 14, 2010 at 7:32 PM, John Kelso ke...@nist.gov wrote:
DGL has its own threading and draw code. It uses OpenThreads
for threading. The OpenGL calls generated by draw() are sent to the
defined windows using OSG's SceneView class and Producer. So, it's
not
Hi.
I use Matrox Dual Head 2 Go for 2 fullscreens
2010/12/17 Alberto Luaces alua...@udc.es:
David Glenn writes:
Chriss10 wrote:
I added eventhandler, but it doesn't work for me!
It does not matter how many times I pess 'f', my application will only be
shown on one screen.
Can
On Thu, Dec 16, 2010 at 3:50 PM, Christina Werner werner...@fh- Can
somebody help?
Other ideas? I think it should be possible to span it over 2 fullscreens.
I don't know what OS you are working with. Often OS's have the
drivers control how the desktop and windows open up on.
I'm only really
Greetings, all.
I've been cleaning up my application, and, somehow, this has triggered
a StackOverflow situation. I'm working on Windows XP, and have been
working with OSG 2.6. In attempting to deal with the problem, I've
updated to 2.8.3, and find that the problem persists.
The symptom is
Addendum:
Having loaded the symbols for user32.dll, the call sequence is:
osgViewer::WindowProc, which calls
osgViewer::GraphicsWindowWin32::handleNativeWindowingEvent.
_windowProcedure is set, so that calls
user32.dll CallWindowProcA
user32.dll IsWindowUnicode
On 12/17/2010 9:13 AM, Katharina Plugge wrote:
Hi,
MultiTexturing has still its problems. Now I tried the first time to use up to
3 textures. Converting to flt again lead to corrupted texture coords. I
attached an osg-file which can be used to reproduce the problem. Converting
this file to
Greetings All!
I checked out the OpenGL forum at Khronos and they suggested to me the save
hack that I dreamed up! Grin! Furthermore, I found out that this is the same
solution for X11 and MS Windows - including Windows7!
I know that I complained to Autodesk the other day about Spanning
Hi Robert,
We are not updating the data frame-to-frame, which is why this is so
baffling. I'm working through the issue with gDebugger now - if you
don't have any suggestions off the top of your head, then I'll start
digging and report back what I find, since I don't have time try and
duplicate
Hi Robert,
Based on your question I went back and did some grepping through the DGL
codebase and I see that DGL does NOT use SceneView or any other OSG code.
It simply uses Performer. I was mistaken when I said earlier than DGL uses
SceneView.
There is an OSG layer that can be used with DGL to
Robert,
Some more data...
Looks like we're drawing approx 100K tri-strips every frame. The
glDrawElements call is the culprit...though I'm still baffled by why
it is so much slower with VBOs than in immediate mode. Perhaps the
drawing isn't sorted by VBO so that all of the triangles drawn from
Oops!!!
In the below, It simply uses Performer. should have read It simply uses
Producer.
Performer is not involved with this problem in any way. 8^)
John
On Fri, 17 Dec 2010, John Kelso wrote:
Hi Robert,
Based on your question I went back and did some grepping through the DGL
codebase
We are currently using version 2.8.1 of OSG, so what I am about to say may not
jive with the version you are using.
1) Look to the console. The console should give you plenty of information on
errors that may be going on inside code. If you see nothing, try changing the
environment variable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/2010 11:25 AM, Torben Dannhauer wrote:
Hiho,
I thought this might be interesting for some of you:
The manufacturer of Microsofts Kinect Sensor released a official driver
package for linux and windows! you can download and read the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/15/2010 11:39 PM, dimi christop wrote:
Are you sure these drivers work for the Kinect.
On the site it states that it only works with a Primesense camera.
And although its the same company that produced both the Primesense camera
and
gave
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2010 08:09 AM, Torben Dannhauer wrote:
Hello Dimi,
the driver ist NOT provided by Microsoft, but by Primesense, the producer
In my opinion Microsofts attitude towards the Kinect drivers is just a good
face to the matters. Kinect was
Holiday Greetings All!
Alberto Luaces wrote:
I have to say that it used to work well at least with OSG 2.4.0. Then
that misbehaviour appeared, but I don't know if it is a problem with the
drivers or with OSG. I think it's more likely a configuration/driver
issue since you are the first
Hi,
I have a model created by 3dmax.The model contains many objects which already
have color or textures.I want to change the color of the model.
I have tried the method to change the material,but it dosen't work well.My code
is:
Code:
osg::ref_ptr osg::StateSet stateset=new osg::StateSet();
up,
(It's so bad it doesnt work)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34956#34956
___
osg-users mailing list
osg-users@lists.openscenegraph.org
21 matches
Mail list logo
