Re: [eq-dev] osgScaleViewer shows no output

[Stefan Eilemann]

Eddy,

On 10. Mar 2011, at 21:47, Eddy [via Software] wrote:

> So, any ideas what could happen?

This works for me (just tested). Can you attach a debugger and provide the full stack traces ('thread apply all bt' in gdb)?


Cheers,

Stefan.

---

View this message in context: Re: osgScaleViewer shows no output
Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.

[Stefan Eilemann]

Good Morning,

On Fri, Mar 11, 2011 at 7:26 PM, Eddie [via Software]
<[hidden email]> wrote:
> As you requested, here's the full stack trace gdb.txt

There is only the stack trace from the node thread, which is blocked
in a pthread mutex when loading the file. From this it does look like
an OSG issue. It could be that OSG is confused since it is called from
a thread which it did not create. I had an issue with this in the
past.

[Stefan Eilemann]

On Mon, Mar 14, 2011 at 5:38 PM, Eddie [via Software]
<[hidden email]> wrote:
> One question though, in osgScaleViewer, does holding down your left mouse
> button translate the model instead of rotate it (like in eqPly or
> osgViewer)?

IIRC yes. osgScaleViewer uses the OSG manipulators, which behave differently.

[Dardo D Kleiner - CONTRACTOR]

On 3/15/11 6:39 AM, Stefan Eilemann wrote:
> On Mon, Mar 14, 2011 at 5:38 PM, Eddie [via Software]
> <[hidden email] </user/SendEmail.jtp?type=node&node=6172280&i=0&by-user=t>> wrote:
> > One question though, in osgScaleViewer, does holding down your left mouse
> > button translate the model instead of rotate it (like in eqPly or
> > osgViewer)?
>
> IIRC yes. osgScaleViewer uses the OSG manipulators, which behave differently.

Actually osgScaleViewer uses Equalizer event handling and manages the eye/center/up on its own (differently than both eqPly and osgViewer). To use the OSG manipulators one must code against the
osgViewer API (for the EventQueue/CameraManipulator) which breaks Equalizer stereo. I have an osgScaleViewer2 implementation/hack that does this and would be happy to share my experiences if requested.

- Dardo

_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com

[Robert Hauck]

Hi Dardo

I'm interested in your osgViewer implementation since I wanted to try this a
while ago too...

Thanks,
Robert

--
View this message in context: http://software.1713.n2.nabble.com/osgScaleViewer-shows-no-output-tp6159274p6172739.html

Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.

_______________________________________________

[Stefan Eilemann]

Robert,

Please think of adapting and integrating it in osgScaleViewer as well,
if you have the time. I'ld like to get rid of SceneView eventually.

Cheers,

Stefan.

---

View this message in context: Re: osgScaleViewer shows no output

[Dardo D Kleiner - CONTRACTOR]

Ok, attached (assuming list accepts attachments, also sent directly).

Note that some of the OSG manipulators (e.g. flight, drive) seem to expect a more accurate clock than eq::Config provides, so they behave a little funny. There's still work there to correctly
synchronize across all viewers. I'm also not totally convinced I'm doing this the "right" way, but its a start...

- Dardo

[Stefan Eilemann]

Hello Dardo,

On Tue, Mar 15, 2011 at 10:24 PM, Dardo D Kleiner - CONTRACTOR [via Software] <[hidden email]> wrote:

Note that some of the OSG manipulators (e.g. flight, drive) seem to expect a more accurate clock than eq::Config provides, so they behave a little funny.

Is the issue the per-node clock precision or the clock synchronization across nodes?

The former can be helped by exposing the getTimef or even getTimed in eq::Config. Iirc the underlying clock has a higher precision than 1ms, it just wasn't needed so far.

Best,

Stefan.

---

View this message in context: Re: osgScaleViewer shows no output

[Dardo D Kleiner - CONTRACTOR]

Stefan, et al -

On 3/16/11 7:11 AM, Stefan Eilemann wrote:
> Hello Dardo,
>
>

> On Tue, Mar 15, 2011 at 10:24 PM, Dardo D Kleiner - CONTRACTOR [via Software] <[hidden email] </user/SendEmail.jtp?type=node&node=6176072&i=0&by-user=t>> wrote:
>
> Note that some of the OSG manipulators (e.g. flight, drive) seem to expect a more accurate clock than eq::Config provides, so they behave a little funny.
>
>
> Is the issue the per-node clock precision or the clock synchronization across nodes?
>

As is often the case, my initial assessment of this issue was incorrect. In fact, the events being added to the queue were using the osg timer instead of the config clock used to set frame stamps,
leading to the erratic behavior. Clock precision is not a problem, the related manipulators now work as expected...

That is now fixed, as are a number of other issues. Please reference the attached for the latest implementation.

Thanks!

- Dardo