Re: [osg-users] intersection with quad mesh: only 3 verticesreturned
From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC Sent: Tuesday, August 02, 2011 4:49 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] intersection with quad mesh: only 3 verticesreturned It is true that QUAD is an OpenGL primitive but the GL driver tessellates it into two triangles underneath the hood. Most (all?) cards today do break them into 2 tris, but nothing in the OpenGL spec says that they have to, or specifies exactly how they should do it. The reason is that the original SGI geometry engine did not split them. It drew quads directly with an odd algorithm for interpolating values across the interior. Quad lives on as a historical quirk, like the panda's thumb. -Mike Garrity -The MathWorks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning on 64bits: cast to pointer from integer of different size
From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 9:37 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Warning on 64bits: cast to pointer from integer of different size Hi Eric, Is there any actual reason why the Carbon API is not 64bit capable? They did have a beta of a 64b carbon. The problem is that carbon is very broad and has a lot of crufty old corners. Getting from the 80% of the beta to 100% was looking pretty impossible. That left them with a choice between saying carbon wasn't supported or saying it was supported with this long, confusing list of exceptions and bugs. They went with the first choice. Was Cocoa itself not once built upon Carbon? No, it wasn't. I'm totally perplexed by Apple's decision on this, it just stuff's up lots of perfectly valid apps from going 64bit for little gain. As for a Cocoa implementation of GraphicsWindow and PixelBuffer, is Cocoa fully threadable? Are there other constraints that it'll apply to the way we open, render to, and get events from the windows? Robert. As to the original question, we run OSG on 64bit Vista, XP, Solaris, OSX, and Linux with no problems, but we don't use the osgViewer library or a couple of the plugins. The core libraries work fine on all of those platforms. It would be nice to clean up some more of the warnings. -Mike Garrity ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shared points (between OSG and the application using OSG)
On 10/25/06, Soheil Sotoodeh [EMAIL PROTECTED] wrote:
Hi Robert,
Thanks, I've checked that, it is a quite extensive
documentation.
I also have two question about the basic types.
Consider that we have a point cloud (a set of points).
As far as I understood, in openGL when we add the
pointcloud by a sequence of glVertex calls, openGL
makes a copy of the coordinate values. Now when we
have OSG we add the points by a osg::Geometry object.
[snip]
Q2: Is there any approach that I can use a custom
point/vec3 (my own type) instead of osg::Vec3 in
osg::Geometry?
By that I mean having shared point objects for both
OSG and my application.
[snip]
Thanks for your suggestions,
Cheers,
Soheil
From: Robert Osfield [EMAIL PROTECTED]
Subject: Re: shared points (between OSG and the application using OSG)
Hi Shoeil,
With real-time graphics go often end up with 3 copies of your imagery
and vertex data, one on the CPU side, one on the OpenGL driver, and
one on GPU.
The OSG supports deallocating imagery automatically once its passed
to OpenGL, so that only OpenGL retains it as a texture object.
Potentially you can do this on the geometry side too, but there are
more pitfalls as all your intersection code will fail.
As for passing custom geometry to osg::Geometry, perhaps subclassing
osg::Array will be sufficient. Not all OSG ops will work though, even
if the graphics works fine.
Hi Robert. I'm currently trying exactly what you describe here.
Creating my own subclass of osg::Array and using it as the vertex
array for a osg::Geometry. I've run into a few rough spots.
Geometry.cpp contains things like this:
const Vec2Array* vec2Array = 0;
const Vec3Array* vec3Array = 0;
const Vec4Array* vec4Array = 0;
Array::Type type = _vertexData.array-getType();
switch(type)
{
case(Array::Vec2ArrayType):
vec2Array = static_castconst
Vec2Array*(_vertexData.array.get());
break;
case(Array::Vec3ArrayType):
vec3Array = static_castconst
Vec3Array*(_vertexData.array.get());
break;
case(Array::Vec4ArrayType):
vec4Array = static_castconst
Vec4Array*(_vertexData.array.get());
break;
default:
notify(WARN)Warning: Geometry::accept(PrimtiveFunctor) cannot
handle Vertex Array type
_vertexData.array-getType()std::endl;
return;
}
which means that user-defined subclasses of Array are not supported.
I could have my subclass return one of the existing values for
getType, but then the static_cast is not correct. I worked around
that with something like this:
const Vec2* vec2Array = 0;
const Vec3* vec3Array = 0;
const Vec4* vec4Array = 0;
Array::Type type = _vertexData.array-getType();
switch(type)
{
case(Array::Vec2ArrayType):
vec2Array = static_castconst
Vec2*(_vertexData.array-getDataPointer());
break;
case(Array::Vec3ArrayType):
vec3Array = static_castconst
Vec3*(_vertexData.array-getDataPointer());
break;
case(Array::Vec4ArrayType):
vec4Array = static_castconst
Vec4*(_vertexData.array-getDataPointer());
break;
default:
notify(WARN)Warning: Geometry::accept(PrimtiveFunctor) cannot
handle Vertex Array type
_vertexData.array-getType()std::endl;
return;
}
and that seems to work OK, but it's not clear to me whether this
is how you intend getType to be used. Do you think that getType is
telling an Array's user what type of data it is holding, or what
type of Array class it is? Currently the two are the same, but if
you add new subclasses of Array, then the difference becomes
important.
There are a few other, similar downcasts of Array in Geometry.cpp.
I haven't seen any in other files.
The application here is that we have geometric data that is
already stored in something other than a std::vector and I'd like
to wrap it up for OSG's use without making a copy. What do you
think would be the best approach here?
Thanks,
- Mike Garrity
- The MathWorks
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Light sources
From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Dave Pugmire Sent: Thursday, August 23, 2007 4:51 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Light sources Hi, How many are allowed? I'm having trouble getting multiple lights. One seems to work fine, but not 2 or 3. Does something need to be enabled? Thanks, Dave The limit is implementation dependent, but the minimum value allowed for GL_MAX_LIGHTS is 8, so that's not your problem. We regularly have scenes with 8, so it isn't an OSG bug. Are you sure you've got the indices all matched up between the modes and the attributes? -MPG- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Controlling render order in subgraph
From: [EMAIL PROTECTED] [mailto:osg-users- Sent: Wednesday, August 01, 2007 7:49 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Controlling render order in subgraph Hey Everyone, I saw a recent post on these boards asking how to control render order for huds using render bins, and I was curious if the same can be done for general subgraphs in a larger scene. I'm placing a sign into my scene using a Billboard with some drawables. The sign should behave like it's a 2D desktop that I can organize flat drawables on. Right now I'm changing depth values for each drawable to control which one is drawn first. For instance, I set the text one unit closer to the eye than the backboard. This works alright, but there is z-fighting when the sign is far away. Could I achieve the same prioritization using render bins? My intuition says that render bins won't help because all graphics objects are treated equally once pushed down the GL pipeline. However, I'm not positive, and I thought asking might help, or perhaps there is an even better way to handle this :-) Thanks for any advice, Chase I'm afraid I don't have OSG code for this, but here's something I've done in the past that worked pretty well. You need a group node for all of the 2D objects. On this node you add a Depth attribute with the WriteMask set to false, but leave the Function at your default. You also add a Stencil attribute, setting Function to ALWAYS, the operation to REPLACE, and the FunctionRef to 1. Now draw the 2D items. After this, you need one more object that draws a big quad in the same plane. For this one, you add a Depth attribute with the WriteMask set to true and the Function set to ALWAYS. You also add a Stencil attribute with the Function set to EQUAL and the FunctionRef at 1. Finally, on this node you add a ColorMask set to false, false, false, false. There's probably a typo in there somewhere, but here's what happens. When we draw the 2D nodes that are parented to that group, they will honor the Z values that earlier nodes have written, but they won't modify the zbuffer. Instead they'll set a bit in the stencil plane. Next we'll draw the quad. This will write Z values but no colors, and it will only do it where that stencil bit was set. This will leave the zbuffer as it would have been if the 2D nodes had been writing Z's. The problem I've had with this in practice is that a few cards/drivers have problems with the colormask=false,false,false,false step. To really get every card in the world to stop writing colors you often need to do a belt-and-suspenders (what's that in English- English? Is belt-and-braces a real expression?) thing and also set LogicOp to NOOP, and everything else you can think of to get the card to listen to you. But this will probably knock you out of the fastpath. The good news is that cards with these problems seem to have gotten pretty obscure at this point. If you don't need to worry about them, then this technique works pretty well. -MPG- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
