[osg-users] Geometry::getVertexPointer()
Got a question I've been meaning to ask for a while. Don's excellent "Using Reference Pointers" paper mentioned that it was OSG's policy was to always use ref_ptr's unless there was a circular reference possibility. However, all of the Geometry::get*Array() functions that return Array objects return naked pointers instead of osg::ref_ptr's. Why is that? Thanks, Randall ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgfadetext
Hi All, has someone the same memory problem with osgText::FadeText:? I'm using the current code from CVS. When running osgfadetext example, my system is rapidly running out of memory . I changed the example code, so it uses osgText::Text and tried again. Now it runs without problems, and memory use is constant. I could reproduce the same issue on another machine. I wonder if it is a driver issue or it has something to do with osgText::FadeText ? thanks, Markus running Linux 2.6.18-kanotix-1 i686 Videocard nVidia GeForce 7600 GS X.Org 7.1.1 [ 1280x1024 @50hz ] GLX Version 2.1.0 NVIDIA 96.26 | Client Shell | Infobash v2.50 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OS Poll
On 11/4/06, c sklu <[EMAIL PROTECTED]> wrote: Ahh, I understand what you were saying, if only StateSets and Drawables contained OpenGL commands Pretty well all OpenGL stata is managed in osg::StateAttribute subclasses, and all primitive drawing in osg::Geometry. Having OpenGL ES versions of this would not be dififcult to implement, one wouldn't need a extra layer of abstraction like Ogre3D has. IMHO, the key to the OSG's extensibility is not having this extra layer of abstraction, there is a 1:1 mapping to OpenGL, adding new state just means adding an extra StateAttribute and often nothing else needs changing at all, its all located in just that extra class. This also helps keep the footprint down and performance up. The biggest problem is likely to fixed math profile OpenGL ES version, as the OSG uses floats all of the place. If you can target the float path then this isn't so much of problem. The next challange is memory footprint. One might have to be quite aggressive in culling parts of the OSG API, static linking would certainly help do this. Templates would also be something you'd have to look closely at. Perhaps compilers tuned for memory could help cope with this. Art path routes would also be something that would need exploring - since the standard OSG plugins map to standard Node, StateAttribute and Drawables, perhaps a custom converter could be employed. I'm up for porting the OSG to OpenGL ES, but would need a comerical project to fund my efforts on it, as I can't afford to run off an do this stuff just for fun, but fun it'd be. Perhaps members of the community could take on the task. Long term I think that a revamped and slimed down "OSG like" scene graph API would be the ideal platform, such as what I wrote about in the Siggraph 2006 presentation. Like OpenGL 3.0 this is quite a way off though. As for Direct3D, nope, that would be a killer for the OSG's. For starters OpenGL is a hardware abstraction layer (HAL). To support Direct3D and OpenGL you'd need to add a HAL abstraction layer, then scene graph would sit ontop of the HAL abstractation layer - a Hardware Abstraction Layer Abstraction Layer. Now you'd need various implementations under this HALAL, you need a Direct3D 7.0, Direct3D 8.0, Direct3D 9.0, Direct3D 10.0, and OpenGL, and OpenGL ES, ok that 6 combinations of backends to support, so rather than an nice 1:1 mapping, you have a 1:6 mapping, if you are wanting to control what happens down on the hardware in you scene graph you'll need to start hardwiring specific paths to specifc backends. It will start to get messy over time. Also developing and maintaining all these backends really forces up the testing matrix you need to have, this will make making releases more a hassel. You'll also spread all your developer resources between all these combinations. Next up is the performance hit of having a HALAL, it won't be freem, the bigger your database the more CPU bound you will mean, and the greater the extra hit of the HALAL will be. Finally extensibility, if you want support new OpenGL extension then you'll need implement the extension itself, then extend the HAHAL too, so that doubling the amount of work, and then you need to think about the implementations for the other pathways. The extensions to the HALAL also require the core API to be modified, so you can't just do it on you local version, you have to dig into the core source code. Consider how osgGL2 was developed - it existed extirely independantly from the core OSG, the same applies to osgNV. A HALAL would force these extensions to be part of the core right away. So software engineering wise it is a very bad solution. In terms of portability what does it buy you? Xbox is the only platform I can think of. If you are stuck with only decent Direct3D support then perhaps a wrapper mapping OpenGL to Direct3D is a work around. This pushes the HALAL into a layer that is entirely indepdent of the OSG, and doesn't require any compromise in the software engineering of the scene graph. Yes there will be a performance hit, but then the HALAL itself has a performance hit, its really just where do you pay for that hit? Such a HALAL is also portable between high level API's so not only OSG would benefit. The advantage of going this route would be that you only pay for the HALAL hit if you don't have decent OpenGL available, everywhere else keeps the clean and fast 1:1 mapping for maximum performance. Robert. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] modelVeiwProj martix
Hi Ben, Its a standard part of the GLSL. See the glsl_*.osg example data and GLSL docs. Robert. On 11/4/06, Benoît Poulard <[EMAIL PROTECTED]> wrote: Hi, how can I give to a shader program the modelViewProj matrix? I don't know how to get it? Thank's Ben ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OS Poll
Ahh, I understand what you were saying, if only StateSets and Drawables contained OpenGL commands On 11/4/06, Paul Martz <[EMAIL PROTECTED]> wrote: > Even the Drawables aren't completely compatible with OpenGL > ES. Currently, that's correct. That's why you'd need to derive your own OpenGL ES-compatible Drawable classes that limit their OpenGL usage to OpenGL ES commands. -Paul > > On 11/4/06, Paul Martz <[EMAIL PROTECTED]> wrote: > > If OpenGL commands were limited to StateSets and Drawables, then it > > would be possible to derive your own "OpenGL ES" versions of these > > classes. As a result, the RenderGraph would be composed solely of > > classes that limit themselves to OpenGL ES commands and > features. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] OS Poll
> Even the Drawables aren't completely compatible with OpenGL > ES. Currently, that's correct. That's why you'd need to derive your own OpenGL ES-compatible Drawable classes that limit their OpenGL usage to OpenGL ES commands. -Paul > > On 11/4/06, Paul Martz <[EMAIL PROTECTED]> wrote: > > If OpenGL commands were limited to StateSets and Drawables, then it > > would be possible to derive your own "OpenGL ES" versions of these > > classes. As a result, the RenderGraph would be composed solely of > > classes that limit themselves to OpenGL ES commands and > features. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OS Poll
Even the Drawables aren't completely compatible with OpenGL ES. I'm no expert but I tried compiling OSG for Windows Mobile with various ogles distributions and things like glBegin/End aren't recognized, so probably only vertex arrays or others are accepted... On 11/4/06, Paul Martz <[EMAIL PROTECTED]> wrote: If OpenGL commands were limited to StateSets and Drawables, then it would be possible to derive your own "OpenGL ES" versions of these classes. As a result, the RenderGraph would be composed solely of classes that limit themselves to OpenGL ES commands and features. It might be nice, down the road, to implement a selectable rendering backend (a la a factory pattern). With current OSG, I imagine memory footprint is a significant issue. A smaller, cleaner, core OSG with limited functionality would be required. Robert has mentioned doing this in the past. -Paul > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of c sklu > Sent: Saturday, November 04, 2006 3:20 AM > To: osg users > Subject: Re: [osg-users] OS Poll > > Any chance of things getting ported to OpenGL ES? I've been > experimenting with developing for Windows Mobile (shudder...) > and am trying to avoid having to write raw OpenGL code, or I > don't even want to think about Direct3D. There is one toolkit > I've found, Ogre3D which allows to switch rendering backends > which is nice because OpenGL performance on my PDA is pretty > poor compared to Direct3D. > > Chris > > On 11/1/06, Don Burns <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Oh, and I would like to see OSG running on a Palm :) > > > > > > I think either the respondents didn't read the "you use with OSG" > > part of the question, or they are just showing off. :) > > > > -don > > > > > > > > ___ > > osg-users mailing list > > osg-users@openscenegraph.net > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > > > ___ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] OS Poll
If OpenGL commands were limited to StateSets and Drawables, then it would be possible to derive your own "OpenGL ES" versions of these classes. As a result, the RenderGraph would be composed solely of classes that limit themselves to OpenGL ES commands and features. It might be nice, down the road, to implement a selectable rendering backend (a la a factory pattern). With current OSG, I imagine memory footprint is a significant issue. A smaller, cleaner, core OSG with limited functionality would be required. Robert has mentioned doing this in the past. -Paul > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of c sklu > Sent: Saturday, November 04, 2006 3:20 AM > To: osg users > Subject: Re: [osg-users] OS Poll > > Any chance of things getting ported to OpenGL ES? I've been > experimenting with developing for Windows Mobile (shudder...) > and am trying to avoid having to write raw OpenGL code, or I > don't even want to think about Direct3D. There is one toolkit > I've found, Ogre3D which allows to switch rendering backends > which is nice because OpenGL performance on my PDA is pretty > poor compared to Direct3D. > > Chris > > On 11/1/06, Don Burns <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Oh, and I would like to see OSG running on a Palm :) > > > > > > I think either the respondents didn't read the "you use with OSG" > > part of the question, or they are just showing off. :) > > > > -don > > > > > > > > ___ > > osg-users mailing list > > osg-users@openscenegraph.net > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > > > ___ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] modelVeiwProj martix
Hi, how can I give to a shader program the modelViewProj matrix?I don't know how to get it?Thank'sBen ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OS Poll
Any chance of things getting ported to OpenGL ES? I've been experimenting with developing for Windows Mobile (shudder...) and am trying to avoid having to write raw OpenGL code, or I don't even want to think about Direct3D. There is one toolkit I've found, Ogre3D which allows to switch rendering backends which is nice because OpenGL performance on my PDA is pretty poor compared to Direct3D. Chris On 11/1/06, Don Burns <[EMAIL PROTECTED]> wrote: > Oh, and I would like to see OSG running on a Palm :) I think either the respondents didn't read the "you use with OSG" part of the question, or they are just showing off. :) -don ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG + ARToolkit
Or why not try osgAR? http://www.gvu.gatech.edu/ael/resources/osgar.html Hello Fernando, You might want to take a look at the amire(authoring mixed reality) project, it does a whole lot more than what you want, but it definitely has an ARToolkit + OSG integration … The last time I worked on the project has been three years ago, so I'm not sure what happened to it afterwards … but you can find it in sourceforge: http://amire.sourceforge.net/ I hope that helps, Best Frank From: Fernando Giovanini [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 9:33 PM To: osg-users@openscenegraph.net Subject: [osg-users] OSG + ARToolkit Hi, I've been looking for how to integrate OSG and ARToolkit. And it seems to work. But I couldn't find any tip in the mailing-list archive. I need to grab the image using a cam, show it in a SceneView window. I read that it can be done using a billboard ou TextureRectangle ou even a [EMAIL PROTECTED], but I can't figure out how to do that. Can you help me a little? Thanks Fernando. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] ModelView matrix math explanation
Another shameless plug, I've found the book: http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Development/dp/1584500379/sr=8-3/qid=1162633178/ref=sr_1_3/002-1104861-1482427?ie=UTF8&s=books to have the best description of the projection and modelview matrices as well as a derivation and an explanation for all the matrix transformations involved and the corresponding OpenGL functions. There are basically the following coordinate spaces: - world/modeling space - eye space - coordinates centered on the camera: +X to right, +Y up, -Z forward - normalized device space: -1<=x,y,z<= 1, but +Z forward, so is left-handed - viewport space Chris On 11/1/06, Jean-Sebastien Guay <[EMAIL PROTECTED]> wrote: Hello, A bit unrelated to OSG, but still in graphics... Does anyone have a good reference to the relationship between the ModelView matrix, the Perspective matrix and the view frustum? I remember that it's something like multiplying an object's vertices by the ModelView matrix brings them in the range [-1,1] for each axis, or something like that, but I can never remember. I seem to remember finding a website on the subject a while back, but I can't find anything now. The general goal is to transform a ray the same way as OpenGL transforms vertices, so that I can make a raytraced picture that corresponds to the realtime OpenGL rendering. I just can't seem to remember the details! Thanks, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Hidden Line Removal
Hi, I just posted an email to this group a little while ago pointing to this website: http://www.opengl.org//resources/code/samples/advanced/advanced96/node54.html#SECTION000121000 I basically implemented this word for word (translating OpenGL to OSG) and it worked perfectly. I think I got it down to only having to traverse the (part of the) scene twice, but then I'd have to look at my code again. Point is, it was pretty trivial using OSG using standard node hierarchy construction and StateSet attributes. Chris On 11/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Another possibility is to adapt a toon shader, but I'm not sure you'd get very crisp results. It'd avoid drawing the geometry twice, and wouldn't pick out _every_ edge. Anyone fancy rewriting a version of Elite that emulates the original BBC micro version... John Donovan Sony Computer Entertainment Europe http://www.scee.com [EMAIL PROTECTED] wrote on 03/11/2006 15:34:05: > Unfortunately, due to differences in polygon versus line > rasterization, a "less or equal" depth test will still produce z- > fighting. (You'd need the old SGI plane equation extension to make > this work, to force line line fragments to have Z values that match > the polygon's plane equation. Most hardware doesn't support this extension.) > > Instead, I'd modify the algorithm below slightly: In the second pass > (when rendering in line mode), enable polygon offset to ensure the > lines don't z-fight with the polygon. > > (As an additional note, this algorithm will only work if you have > polygonal geometry.) > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > 303 859 9466 > > > > The OSG does not have such a built-in feature afaik > Maybe you can draw your object in the z-buffer (disabling the color > buffer output) and then draw the wireframe in the color buffer with > a "less or equal" depth function. > Well, this is the approach I would use; implementing the technique > described in the article seems very difficult, but it might be > possible with a (very complex) shader. > > Thibault > > ___ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify [EMAIL PROTECTED] This footnote also confirms that this email message has been checked for all known viruses. ** Sony Computer Entertainment Europe ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] read buffers back with own CameraNode
Hi Oliver, You can implement your own custom RenderBin's and RenderStage's. This is where the StateSet::RenderBinDetails comes in - it provides the name of the RenderBin/Stage. osgUtil::RenderBin also has methods for registering prototypes of the RenderBin/Stages, these prototype are cloned. However, it would probably be best to just tweak the existing osgUtil::RenderStage to do what you need then submit it for review/inclusion with the core OSG. Robert. On 11/4/06, Oliver Kutter <[EMAIL PROTECTED]> wrote: Hi Robert, Is it possible to implement my own RenderStage with some new functions I need, which inherits from osgUtil/RenderStage and set it to the SceneView with setRenderStage(...)? Is then the new RenderStage completely responsible for the render-to-texture part? Can I also use it to manually read back the z-buffer? regards Oliver Robert Osfield schrieb: Hi Oliver, The rendering is done in the OSG's rendering back end, which is populated by the cull traversal. The CameraNode just controls how this rendering back end is set up. The place in particular where all the RTT stuff happens is in src/osgUtil/RenderStage.cpp. For read back the thing to do is attach an osg::Image. I recall a use having a problem with this for z buffer read back a while back, I don't recall enough what the resolution if any was. Robert. On 11/2/06, Oliver Kutter <[EMAIL PROTECTED]> wrote: Hi, I want to do some buffer read back, e.g. read out z-buffer values or texture values from fbo render targets. How can I do this? My idea was to inherit from osg::CameraNode and implement an own CameraNode. But I can't find out where the rendering is done. When and where is the rendering of the camera done? Or can I do it anyway else? regards, Oliver ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] read buffers back with own CameraNode
Hi Robert, Is it possible to implement my own RenderStage with some new functions I need, which inherits from osgUtil/RenderStage and set it to the SceneView with setRenderStage(...)? Is then the new RenderStage completely responsible for the render-to-texture part? Can I also use it to manually read back the z-buffer? regards Oliver Robert Osfield schrieb: Hi Oliver, The rendering is done in the OSG's rendering back end, which is populated by the cull traversal. The CameraNode just controls how this rendering back end is set up. The place in particular where all the RTT stuff happens is in src/osgUtil/RenderStage.cpp. For read back the thing to do is attach an osg::Image. I recall a use having a problem with this for z buffer read back a while back, I don't recall enough what the resolution if any was. Robert. On 11/2/06, Oliver Kutter <[EMAIL PROTECTED]> wrote: Hi, I want to do some buffer read back, e.g. read out z-buffer values or texture values from fbo render targets. How can I do this? My idea was to inherit from osg::CameraNode and implement an own CameraNode. But I can't find out where the rendering is done. When and where is the rendering of the camera done? Or can I do it anyway else? regards, Oliver ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
