. They can render to a texture which can be used
> either in the
> scene, like in a video screen in the instrument panel, or
> for distortion
> correction in a projected or dome environment.
>
> Open Scene Graph supports a CompositeViewer object that
> supports
> rendering from
kat' for the
> other screen.
>
> Neither of these are supported at the present time, but it would be a good
project. We would have to start using a different OSG class,
CompositeViewer, to support multiple views from independent view points. Our
terrain pager would need a complete overhaul
in a projected or dome environment.
Well, I have an animation that I call rendertexture, where you can replace a
texture on a subobject with such a rtt camera. Then specify a usual
scenegraph to render to that texture and voila. I believe that I could finish
that in a few days - depending on the we
for
> > distortion correction in a projected or dome environment.
> Well, I have an animation that I call rendertexture, where you can
> replace a texture on a subobject with such a rtt camera. Then specify
> a usual scenegraph to render to that texture and voila. I believe
> that I coul
n in the instrument panel, or for distortion
correction in a projected or dome environment.
Open Scene Graph supports a CompositeViewer object that supports
rendering from several widely separated viewpoints, complete with
support for multiple terrain pag
cation" for the terrain pager, but more
> on that later.
>
> This proposal is a little vague; the specifics need to be worked out
> when the CameraGroup is implemented and FGViewer is changed to use it.
>
>
> Future Possibilities.
>
> The cameras in a camera group don
> This proposal is a little vague; the specifics need to be worked out
> when the CameraGroup is implemented and FGViewer is changed to use it.
>
> Future Possibilities.
>
> The cameras in a camera group don't need to render directly to the
> screen. They can render to
ry is svgl at svgl.sourceforge.net, but I have no idea if it is
still alive. Any solution that renders to memory using the CPU is going to be
too slow, IMHO.
A moving map is a different beast. It would make sense to implement that as a
scene graph in its own right with its own pager. That would
e runs pure vector and it runs smoothly
even on a 7-year-old Celeron without a 3D card. And for the record,
that's on Windows 2000.
>> A moving map is a different beast. It would make sense to implement
>> that as a
>> scene graph in its own right with its own pager. That
vector formats, but I'd be happy to use
a mixture of simple vector graphics and bitmap textures to start with,
and the replace the textures with vector art once there's a suitable
renderer.
Anyway, going to play with svgl now.
>
>
> A moving map is a different beast. It w
tiple view
> positions (e.g. one screen for the tower view and a second screen for
> the plane) would complicate a "locked to cache" flag quite a lot...
>
Yes, and that's not really supported by the current architecture, neither by
the tile cache
11 matches
Mail list logo
