Encoding Geode id in pixel color and then reading prerendered texture by CPU
is
a rather brute force aproach, but fairly simple and open for some
optimizations (like using lower RTT resolutions). If run on PCI express
board it could be even fairly quick ;-)
I thought about simple color encoding which puts 4 bytes of 32 bit
identifier into R G B A components. If one needs to preserve alpha there
should be still enough (around 16 millions) of discrete values in 24 bit R
G B range. But if one may use RTT 32 bit RGBA buffer it could be possible to
use even a pointer to geode if application is compiled in 32 bit
environment.
I don't know how simple it would be with OSG but with RTT multibuffers we
could extend this ID range even more. Or one may use them to display both
actual color output in one buffer and geode ids in second buffer.
Cheers,
Wojtek Lewandowski
----- Original Message -----
From: "Oliver Schoenborn" <[EMAIL PROTECTED]>
To: "osg users" <[email protected]>
Sent: Friday, June 22, 2007 6:01 PM
Subject: Re: [osg-users] fast "is-visible" test
Interesting strategy, along the lines of a reply I posted earlier in this
thread (also uses two-pass rendering), but a different tack on how to get
the cell. I think the color coding would make shader part easier to code,
thanks for the idea.
It's also a clever way of getting stuff out of a shader program, has this
been used as a technique for debugging shaders? I.e.
* the first render uses a CameraNode that has exact same settings as
SceneView as well as same child (scene graph) but uses RTT;
* a uniform is used to turn debugging "on" for everything under the
camera node; this allows the shader to encode state of variables
as colors in the rendering buffer;
* the second pass would use a pre-draw callback on the sceneview to
read the output of first pass, and decode info, and call printf
(e.g.);
* one limitation is that an integer code would have to be used by
shader so code in osg knows how to decode info (int, bool, float,
Vec3, etc) in image, but both sides of the capability (code on
shader side and decode on app side) could probably be factored out
into resusable components (shader files with functions, and a dll).
* another is that only fundamental types could be transfered (no
structs, just their non-struct attributes)
Another item to add to my list of "needs more investigation" items :)
Cheers,
Oliver
Wojciech Lewandowski wrote:
What about following concept:
Encode unique geode ID onto geode pixel color.
Render A scene to texture.
Read texture to image and read image to find visible geodes by comparing
their pixel IDs ?
Cheers,
Wojtek Lewandowski
----- Original Message ----- From: "Oliver Schoenborn"
<[EMAIL PROTECTED]>
To: "osg users" <[email protected]>
Sent: Friday, June 22, 2007 1:59 PM
Subject: Re: [osg-users] fast "is-visible" test
It could be either extreme: any pixel seen, or whole object has to be
seen. But just being in view frustum is not enough (could be wholy or
partially occluded by other objects). Thanks,
Oliver
Robert Osfield wrote:
Hi Oliver,
How exactly would you define being "look at"? Any part of the model
in the view frustum, any pixel on the objects seem?
Robert.
On 6/21/07, Oliver Schoenborn <[EMAIL PROTECTED]> wrote:
I would like to change the color of a geode in one scene view (call it
B) based on how "often" a geode is visible in another scene view (call
it A). I.e., the longer the geode is being "looked at" in A, the
brighter its corresponding geode gets in B, up to some saturation
value.
If I only had a small number of such geodes I could use
IntersectVisitor
but I have a large number of them (about 1 million), so I'm looking
for
better ways.
I suppose a fragment shader might work, if two conditions are met:
1. Textures (as 2D arrays) can be written to by one shader, and
read
from by another
2. A shader only gets called for a fragment if fragment is
visible --
not occluded by anything else.
Any easier way? Any comments on above greatly appreciated.
Oliver
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
--
Oliver
skype: schoenborno
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
--
Oliver
skype: schoenborno
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
