Re: [osg-users] Setting a monochrome 2d texture from byte array
Hi, Thanks for the responses. I tried Robert's initial suggestions, but they get Code: Warning: detected OpenGL error 'invalid value' at after RenderBin::draw(..) on my system. Glenn's suggestion basically worked, although the image was literally shades of red. So I looked at the DefaultFont source, and tried GL_ALPHA. Maybe that would have worked if I turned alpha blending on etc. So just for kicks I tried GL_LUMINANCE (for internal and pixel format) and it worked! So, for the record, here is what worked best for me: Code: img->setImage(w, h, 1, GL_LUMINANCE, GL_LUMINANCE, GL_UNSIGNED_BYTE, data, osg::Image::USE_MALLOC_FREE); // works! Thank you! Cheers, Steve -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76880#76880 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Setting a monochrome 2d texture from byte array
Hi,
I am trying to render a monochrome camera image to a 2d texture, but without
success unless I first convert it to BGR.
After reading
http://forum.openscenegraph.org/viewtopic.php?t=16236
I got closer, but still no cigar as the result is a boring uniform black. Here
is some code:
Code:
void VSGeode::setImageParameters(bool linear)
{
if (getNumDrawables() < 1)
throw OSGWrapException("No drawables");
quad = dynamic_cast(getDrawable(0));
if (!quad)
throw OSGWrapException("No geometry");
osg::StateSet* state = quad->getStateSet();
if (!state)
throw OSGWrapException("No state");
tex = state->getTextureAttribute(0,
osg::StateAttribute::TEXTURE)->asTexture();
if (!tex)
throw OSGWrapException("No texture");
tex->setFilter(osg::Texture::MIN_FILTER,linear ? osg::Texture::LINEAR :
osg::Texture::NEAREST);
tex->setFilter(osg::Texture::MAG_FILTER,linear ? osg::Texture::LINEAR :
osg::Texture::NEAREST); // NEAREST for pixelated look, LINEAR for smooth.
img = tex->getImage(0);
}
void VSGeode::setImageBGR(int w, int h, unsigned char * data)
{
img->setImage(w, h, 1, 3, GL_BGR, GL_UNSIGNED_BYTE, data,
osg::Image::USE_MALLOC_FREE);
quad->dirtyDisplayList();
}
void VSGeode::setImageMono8(int w, int h, unsigned char * data)
{
img->setImage(w, h, 1, GL_R8UI, GL_RED_INTEGER, GL_UNSIGNED_BYTE, data,
osg::Image::USE_MALLOC_FREE); // black
quad->dirtyDisplayList();
}
SetImageBGR() works fine, but as mentioned, setImageMono8() does not.
What happens is that the image comes in from a hi-res GigE camera, and it is a
monochrome byte array. Because this is already fairly CPU intensive, I wish to
avoid another copy to expand into a BGR array. But for the life of me I can't
work out a magic combo of parameters that actually works. The data really is
there, since I can fake it and just call setImageBGR() and it comes up with
something, albeit like a Degas painting.
So what is the most efficient way of getting a grey-scale image in a texture,
from a 2D byte array in memory?
Thank you!
Cheers,
Steve
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76871#76871
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersection with 2d plane embedded in 3d
Hi Robert, Thanks for the reply. I take it that quad intersection is the right approach for this problem. So follow-up question: what would be a good way to improve efficiency? I know exactly which quad to intersect, but don't want intersection to test against all the other zillions of geodes in the scene. It looks like the same node mask trick can be used with the intersection visitor, so hopefully I can use another node bit for that - although it looks like I have to turn off that bit in all except the node path from camera to quad. Cheers, Steve -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76123#76123 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersection with 2d plane embedded in 3d
Trying to answer my own question by using the form of
View::computeIntersections() which takes a node path parameter. The following
code (as a member of my View subclass) doesn't seem to work (even though the
simpler deprecated form works)...
Code:
osg::Geode* geode = ...;
osgUtil::LineSegmentIntersector::Intersections intersections;
osg::NodePathList npl = geode->getParentalNodePaths(getCamera());
npl[0].push_back(geode); // Not sure if this req'd, but it fails either way
if (computeIntersections(getCamera(), osgUtil::Intersector::WINDOW, x,y,
npl[0], intersections)) {
printf("\n");
}
It never gets to the printf. (Yeah sorry but too late to teach this old dog to
use cout).
Can't find any examples of creating node paths like this, so I'm probably not
understanding how it works. Do I need to push the camera node to the front?
The geode to the end?
Cheers,
Steve
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76121#76121
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Intersection with 2d plane embedded in 3d
Hi, Is there any way to create a "virtual infinite" quad (i.e. plane) that satisfies the intersection test, but without being rendered itself? Or is there a good way of converting screen coordinates to "local" embedded 2d model coordinates? Motivation: My application has line strips and other 'skinny' geometry which are all defined with a zero Z value hence are basically 2d, but are embedded in a 3d model under some DOF transforms. I wish to find the 2d local coordinate corresponding to a mouse click. I can do this by defining a quad then using a line intersector, but if I hide the quad behind, say, a switch node which is turned off, then the intersection does not work. Maybe that's because I don't know how to restrict computeIntersections() to start at a particular node in the tree. Anyway, a quad needs a particular size, but I really want the plane intersection, not just part of it. Ultimately, though, I am happy to define a big quad provided I can avoid rendering it. Thank you! Cheers, Steve -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76120#76120 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG in Gtk3 GLArea
Hi Robert, OK I will check out the resize policy settings. Excellent point about inverting the projection matrix. Since the last post, I managed to eliminate most of the copying, with the single remaining copy reversing the pixel row order on-the-fly. Since that copy is unavoidable, in the end it probably wouldn't save much time to invert the rendering. One question I do have: in the screencapture sample that I based this off, there are 4 options: read pixels, and 1- 2- or 3 pixel buffer objects. I assumed that single PBO is appropriate for this use (since our application doesn't demand super smooth high frame rates or anything, 15Hz is adequate). But to minimize CPU involvement, is this the best choice? It's getting close enough to be a workable backup plan, so next step would be to try your suggestion of copying between GL contexts. Cheers, Steve -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73988#73988 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG in Gtk3 GLArea
So far, the kludge solution is almost working. I needed to add glPixelStorei(GL_PACK_ALIGNMENT, 1); before glReadPixels() otherwise it broke if the window width wasn't a multiple of 8. Problems remaining: 1. the aspect ratio does not adjust properly on window size changes, so that the scene just stretches like rubber. 2. there is a truly horrendous amount of copying data. For (1), I was assuming that camera->setViewport(new osg::Viewport(0,0,width,height)); camera->setProjectionMatrixAsPerspective(30.0f, 1.*width/height, 1.0f, 1.0f); on the slave and main (?) cameras would fix that up, but no. Maybe there's something cached somewhere, even though I am completely reconstructing the slave camera on each resize. Any suggestions where to look? For (2), after the hardware renders the scene, and the PBO is mapped back into userspace RAM, the following copies occur: - memcpy to the osg::Image data - image->flipVertical() since 2D library has Y inverted w.r.t GL. - copy to a new Python string object - copy to a new GdkPixbuf object - copy to the cairo context (that's the Gtk 2D graphics engine). I think a lot of this could be eliminated by creating the GdkPixbuf directly from the PBO map, flipping the row order in this copy. Although it performs OK, we have to run on low-end systems. Cheers, Steve -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73985#73985 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG in Gtk3 GLArea
Hi Robert, The full application uses the following: - read .wrl files using osgDB::readNodeFile() - create geometry nodes dynamically with quads, lines, line strip. - billboards with text - osgSim::DOFTransform, osg::MatrixTransform - osg::Camera (additional cameras for HUD or inset display) - osg::TextureRectangle (we live video feed to textured quad(s)) - in the osg::StateSet we set modes for GL_NORMALIZE (sine we need to scale the VRML models), GL_BLEND (translucent quads), 2-sided lighting, Hope that's the info you were asking for. For the current test case, however, I have stripped it down to just quad-based geometry and a few transforms, single-sided, single world lighting. To make things just a bit more complicated, I'm actually calling from Python code, so the OSG API is selectively wrapped using boost::python. I don't think that's an issue at present. I know practically nothing about shaders, so I'll take any recommendations for reading material. Cheers, Steve -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73981#73981 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG in Gtk3 GLArea
Hi kornerr, Thanks for the heads up. I'll give it a try when I get back to core profile work, which I will feel better about once I have a kludge that works well enough to keep the boss happy. We basically use only geodes, switches and model transforms, along with some state settings like blending. So I'm hoping that there's not too many more implementation details to worry about. Cheers, Steve -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73976#73976 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
