Hi Csaba,
I have finally cleared through my inbox to looking closely at this
issue and the suggested bug fix. I believe your suggested change is
safe in normal execution for CullThreadPerCameraDrawThreadPerContext
and DrawThreadPerContext, as the the _startRenderingBarrier barrier
being joined
On Thu, Oct 16, 2008 at 2:42 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
HI Csaba,
I suspect the particular problem you are seeing is not directly driver
related, but is an OSG bug, differences in drivers might change the
timing slightly which leads to the problem not becoming visible, but
Hi Csaba,
Given the provided details I don't have enough to provide an clues to
what might be up.
Try different threading models to see what results you get.
Also try the standard OSG examples to see if any of them hang.
Robert.
On Wed, Oct 15, 2008 at 9:58 PM, Csaba Halász [EMAIL PROTECTED]
HI Csaba,
On Thu, Oct 16, 2008 at 1:29 PM, Csaba Halász [EMAIL PROTECTED] wrote:
The other threading models seem to work, and the osg camera example
works with CullThreadPerCameraDrawThreadPerContext too.
I wonder if the problem reported by Paul in the mail thread Please
test SVN of
On Thu, Oct 16, 2008 at 2:42 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
CullThreadPerCameraDrawThreadPerContext is the most complex of all the
osgViewer threading models, and with it the widest range of different
thread/barrier combinations. It could be that you are using a
combination of
Hi again,
Now that I got threading running, I have run into this trouble:
draw() 0xee0b20
draw() got SceneView 0xf18a80
end draw() 0xee0b20
draw() 0xda1f80
cull()
cull() got SceneView 0xf03e90
end cull() 0xee0b20
cull()
cull() got SceneView 0xf7b020
_clampProjectionMatrix not applied, invalid
6 matches
Mail list logo
