[osg-users] Counting OpenGL Draw calls in Stats
Hi, all, I'm interested in determining how many OpenGL draw calls are made during the rendering of a frame (counting and storing them as a Stats variable). I'm sure this is possible, but I wonder if it would be feasible to do without significantly affecting performance. Anyone have any thoughts? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Counting OpenGL Draw calls in Stats
Thanks, Bob. I've used gDEBugger for this before, but for this case, I need to get it into the OSG Stats proper. The capability isn't there yet, so I'm looking into adding it. I'm trying to gauge how feasible it would be to add this feature without adversely affecting performance. The current frame Stats don't seem too heavy, but they're mainly taking measurements before and after the frame, not counting events that happen during the frame. --J On 02/22/2012 03:22 PM, Buckley, Bob CTR MDA/DES wrote: gDEBugger has the ability to view OpenGL Call history. Can't speak on the performance hit. But, sounds like you need it in the app itself. I don't know of an internal mechanism. However, should be able to easily CASE a thin inlined OpenGL layer with metrics embedded. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Daly Sent: Wednesday, February 22, 2012 11:35 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Counting OpenGL Draw calls in Stats Hi, all, I'm interested in determining how many OpenGL draw calls are made during the rendering of a frame (counting and storing them as a Stats variable). I'm sure this is possible, but I wonder if it would be feasible to do without significantly affecting performance. Anyone have any thoughts? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Counting OpenGL Draw calls in Stats
On 02/22/2012 05:53 PM, Buckley, Bob CTR MDA/DES wrote: A co-worker sent me this: http://www.opengl.org/sdk/tools/GLIntercept/ It wraps opengl32.dll so that it can log all calls to OpenGL Unfortunately, it appears to be Windows only. Hi, Bob, I'm not really interested in any other solutions outside of OSG itself. What I'm considering specifically is adding code to count the actual OpenGL draw calls made by OSG (mainly in PrimitiveSet.cpp) and placing the count into an osg::Stats variable (much like the FPS, update, cull, and draw times, number of groups and geodes in the scene, etc). I'd like to add GL draw calls as a stat that can be queried in code (and conceivably could be put into the StatsHandler display). I'm just not sure whether or not collecting this count would be too heavy for general use. If it can't be done without a driver layer or some kind of non-standard instrumentation (like gDEBugger), then we'd rather just not do it. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Animated skybox? Feasible in OSG?
On 02/21/2012 03:08 AM, Sergey Polischuk wrote: Hi, Christian You can do this, although can say anything about hardware accelerated decoding... that depends on backend of plugin that you use for movie loading to osg (there are xine ffmpeg directshow and quicktime plugins in osg for video decoding, i dont know for sure if any of these use hardware accelerated video decoding) I think the more recent versions of ffmpeg have some support for VAAPI as well as nVidia's VDPAU, which would work for Linux. There may also be support in ffmpeg for Apple's VDA. For Windows, you might be best off with the DirectShow plugin, which should benefit from DxVA. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Etende light source example
On 02/16/2012 05:38 PM, Sajjadul Islam wrote: So it is posible to implement it with GLSL and could you provide me with some reference materials ? A quick Google search for (GLSL area lights) found this: http://www.gamedev.net/topic/552315-glsl-area-light-implementation/ --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] set render bin details
On 02/16/2012 08:22 AM, Sajjadul Islam wrote: Hi, I am going through an osg example and one point there is a statement as follows: Code: stateset-setRenderBinDetails(-1,RenderBin); When OSG traverses a scene for rendering, it organizes geometry into separate render bins. Each bin has an index and a sorting mode. When it comes time to actually draw the geometry, the render bins are traversed in order of index (lowest to highest), and the geometry in those bins are drawn after being sorted according to the sorting mode. In this case the index of -1 means that the geometry in this bin will be drawn before the rest of the geometry (which by default goes into bin 0). RenderBin is the default sort order (which happens to be SORT_BY_STATE). In this case, there must be some geometry that is required to be rendered before the rest of the scene. Since you didn't mention which osg example you were looking at, that's all I can say about it. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Etende light source example
On 02/16/2012 07:57 AM, Sajjadul Islam wrote: Hi, Is there any example of extended light source for example , rectangular light source inside the osg repository. I could not locate it in the repository, please help me to locate if i missed it there. I think OSG is currently limited to the OpenGL light sources (point, spot, and directional light sources, as well as ambient light). There isn't currently any code to handle global illumination in OSG, so area lights (like rectangles) don't really mean much anyway. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to prevent resize of viewer window (Windows and Linux)
On 02/16/2012 08:46 AM, John Simpson wrote: Hi, For info: this can be achieved using... osgViewer::ViewerBase::Windows windows; viewer.getWindow(windows); windows[0]-setWindowDecoration(false); But this also prevents the window being moved - not ideal. Hi, John, There should be a better way to do that: osg::GraphicsContext::Traits *traits = new osg::GraphicsContext::Traits; traits-x = 100; traits-y = 100; traits-width = 640; traits-height = 480; traits-windowDecoration = true; traits-supportsResize = false; traits-sharedContext = 0; osg::Camera *camera = new osg::Camera(); camera-setGraphicsContext(gc); camera-setViewport(new osg::Viewport(0, 0, traits-width, traits-height)); viewer.setCamera(camera); viewer.realize(); Haven't tested this code, but something like that should be enough to get what you're looking for. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawing poly line, jitter/vibration issue when moving camera
Hi, Preet,
Robert is probably offline now, so I'll attempt to pick up where he left
off...
On 02/14/2012 12:47 PM, Preet wrote:
I didn't understand what was meant by local origin here. Let's say I
have a model of the Sphinx I want to show on the surface of the Earth
(coincidentally I'm trying to display geospatial data).
Are you suggesting that I draw the model with coordinates relative to
the origin of of the scene first ('local'), then parent the
corresponding geode with a matrix transform that scales/moves/rotates
it out to the correct position on the Earth's surface ('world
coordinates')?
Exactly. This would allow the vertex coordinates (which are represented
with 32 bit floats) to work with enough precision to prevent the
instability you're seeing.
I found a few references online to a somewhat similar solution that
suggested transforming the entire scene so it's centered at the origin
before passing it to OpenGL. Is this a worse or better approach than
the suggested fix?
I'm not sure I follow this question. Centered at what origin?
I understand that numerical precision decreases when rendering a scene
further from the origin, because there are a finite set of numbers you
can represent in floating point. Using doubles for the transform and
carrying doubles throughout the scene graph traversals increases
precision right up until the data is passed to OpenGL. I didn't quite
follow your explanation about the camera and geometry translations
cancelling out though... could you expand on this a bit?
Both the camera's View matrix and the transforms in the scene (which
will be accumulated by OSG into a Model matrix) are represented with
doubles by default. This gives them plenty of precision to represent
large values.
Now, say you move the camera close to your sphinx model. This will
cause the Camera's View matrix to have a translation value that is close
to the inverse of the sphinx's accumulated Model matrix.
When the scene is traversed for rendering, the Model and View matrices
are combined into the OpenGL ModelView matrix, which must now be
represented as floats. However, the large (but opposite) translation
values will combine to a ModelView translation that is relatively small
before the matrix is sent to OpenGL. This means that the transformed
vertex coordinates will also be relatively small, and they'll still have
plenty of precision to work with when they're sent down the OpenGL
pipeline for rasterization.
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ffmpeg and OSG
On 02/08/2012 07:39 AM, Donn Washburn wrote: One mixed version is the openSuSE factory 12.1 version and a SVN/GIT version (current) from ffmpegs site.. About one year ago I had the same problem. ffmpeg-0.9.1-1.1.x86_64-openSuSE does renumber and installs them by lib64s (libav* +libsws*) gstreamer-0_10-ffmpeg-0.10.11-1000.4.x86_64 They also failed The following is a SVN/GIT number set /usr/lib64/libavcodec.so.54.1.100 on this machine currently. There has been others versions going back to about 1 year. Please note openSuSE only has libav codec53, libavfilter1, libformat52, libavutil51 and libswscale0. NO libpostproc or the others If you need more please let me know. Just a note that ffmpeg seems to be under new management these days, and they are making an effort to keep things stable for longer. The current versions of ffmpeg are 0.7.11 (ABI compatible with the 0.6 version), 0.8.10, 0.9.1, and 0.10. All of these versions are now actively maintained (though new features only show up on the latest branch, obviously). Instead of using ffmpeg SVN, you might consider picking a stable release that is already compatible with OSG. It's not as necessary to use SVN to get the best version of ffmpeg as it used to be. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ffmpeg and OSG
On 02/08/2012 06:34 PM, Donn Washburn wrote: I did try ffmpeg-0.10 and OSG did make it. However, at about 92% it complained about ffmpeg to about 96%. The errors are depreciated and warning as I remember Those are probably because OSG isn't ready for ffmpeg-0.10 yet (it just came out last month). You might want to try the 0.7.x or possibly the 0.8.x release. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Case IN-sensitivity for osgDB when searching for files
On 02/03/2012 04:55 PM, Chris Hanson wrote: Ran into a problem where models made on a Windows box didn't work on a Linux box because the modeler had stored texture filenames in the file in one case foo.jpg and the actual image file was a different case foo.JPG. Obviously the solution is to fix the model, but unfortunately, I am dealt the task of dealing with clueless modelers and yet-unborn clueless models in the wild. I believe I could rig some code to, in the event of a failure to locate a file, get a directory listing of each osgDB search path, and attempt a case-insensitive string compare looking for a file that matches, and then load that. My questions are: Is there a better way to do this or away to do this already? Is there an osgDB callback that I could hook into that would let me make one last-ditch effort at finding a file before osgDB gives up? I suspect I'd have to use something like BOOST::filesystem to do the directory listing in a portable manner, which means this would be code that couldn't be in core OSG (because of BOOST), hence the callback. If there's a better way to do this within core OSG, and it would be a welcomed submission, I'd be happy to do it that way too. Obviously it would have to be an optional behavior since not everybody on Linux/OSX wants artificial case insensitivity. Hi, Chris, In case you weren't aware, osgDB::findFileInPath (and it's companion, findFileInDirectory) has an option for case insensitivity. I had to deal with a similar problem when I was writing the .mdl plugin (apparently, Valve's artists didn't care much about matching case, either). Of course, I had the advantage that I could specify CASE_INSENSITIVE in the plugin, and know that it would be OK in all cases. That's probably not true in your case. Still, if you can figure out a way to hook in your last-ditch effort, there's already a tool to help. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/27/2012 04:38 AM, Sergey Polischuk wrote: As a side note: if you were using vbo's instead of display lists for drawing i think you werent get into this problem in first place, as with vbos 5500 draw calls would happily kill your performance even on one screen, so you have to optimize your models. Nvidia drivers are great at optimizing consecutive calls to draw display lists so they become cheap as dirt and you can do thousands of them, may be this fails on multiple screen setups? Hi, Sergey, I did play around with VBO vs. display lists early on. It didn't really change the performance much regardless of which I used. Keep in mind that this is all static geometry which is going to be resident on the GPU. I don't think modern drivers would distinguish much between VBO's in STATIC_DRAW mode and display lists. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi, Paul, As Tim pointed out earlier, the more limiting resource is likely to be lock contention in the NVidia driver instead of bus contention. Note that Bb is going to be 4000 MB/sec (500 MB/sec * 8), per Quadroplex (PCI-e 2.0 8x) on the NIST machine. On my system I have an X58 chipset, so it's even wider (500 MB/sec * 16) per card. Also, the NIST machine's FSB is limited to 1.6 GT/sec, which is less than the 5 GT/sec that PCI-e provides. Given that the data is static (we're not transferring any vertex data over the bus, just making glDrawElements calls to VBOs in STATIC_DRAW mode), I doubt that the OpenGL command stream is going to be getting anywhere near the actual bus bandwidth. On 01/27/2012 09:17 AM, Paul Martz wrote: Hi Jason -- I agree that the system bus is a likely source of the scaling issue. It is certainly a single resource that has to be shared by all the GPUs in the system. To make a case for bus bandwidth limitation, you might work through the math. Bb FPS = Nw * Nd * Sd + O Where Bb is the bus bandwidth in bytes, Nw is the number of windows you're rendering to, Nd is the number of drawing commands, Sd is the size of the drawing commands in bytes, and O is the per frame OpenGL command overhead in bytes. The knowns: Bb = 500 MB/sec (PCIe 2.0) Nw = 4 Nd = 5500 Sd is a little harder to compute. It'll depend on the draw technology you're using (buffer objects or display lists) and the underlying OpenGL implementation. You could make a very rough guess here by figuring a fullword per OpenGL command, and a fullword per OpenGL command parameter. Just for the same of example, let's says Sd = 64 (16 fullwords to draw a single osg::Geometry). O encompasses all the per-frame OpenGL commands that OSG emits: glClear, glClearColor, glClearMask, dlDepthMask, matrices, light sources, swap, etc. You could plug in a rough guess like you would for Sd. Again, just as an example, let's use O = 2048. Plugging all that into a calculator, I get FPS = 371. But if Nw dropped to a single window, then FPS would jump to over 1400 -- or, more likely, you'd become limited by some other single resource in the system. The nice thing about algebra is that you can solve for the unknown, so of course you have the FPS, and if you have a pretty good guess for O (which can actually be pretty sloppy anyhow), then you ought to be able to solve for Sd and ask yourself if that result makes sense. I hope this helps. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/27/2012 02:12 PM, Paul Martz wrote: Sorry, I was going off your post that read This leads me to believe that bus contention was causing the lack of scalability. I was just trying to outline a way to validate that suspicion. If you've already ruled out bus contention, then disregard my post. Hi, Paul, I'm not dismissing your post at all. It's certainly worth thinking about the overall bandwidth, and how much of it might be consumed by the GL command stream. I like your equation as a general guideline. One just has to keep in mind that 500MB/sec is the bandwidth for a single PCI-e 2.0 lane. Most graphics cards get 8 lanes, if not 16, and that's per card. You also have to account for the CPU interconnect bandwidth, which may put an upper limit on how much data you can transfer with multiple cards (theoretically 12.8GB/s on this hardware). In this particular case, I think Tim is right. There's not enough data in the command stream to get near the bus bandwidth. In this case, there are two 8x PCI-e cards (total of 8GB/s bandwidth) feeding 4 GPU's (two QuadroPlex D2 units). Using your figures: 2 * 8 * 500 MB/s - = 5648 Hz 4 * ( (5500 * 64 B) + 2048 B) So, unless I'm missing something, the problem must be elsewhere :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/27/2012 04:17 PM, Doug McCorkle wrote: We run a very similar system with 5 quadro cards and do not run into these problems with very large models. We are using VR Juggler though. I mention this because it would be very straight forward to use one of the sample OGL VR Juggler examples as a test application that would load an OBJ file or something to provide a raw OGL benchmark for the hardware. You could also use one of the sample OSG applications to do a comparison to at least provide a place to start working from in terms of figuring out your core issues. Hi, Doug, It may not have been easy to find in the mountain of text from the original post, but I did end up writing a multithreaded pure OpenGL program in an effort to eliminate OSG as the culprit. Since we ultimately ended up getting a similar frame rate drop in both OSG and OpenGL, we pretty much have eliminated OSG as the culprit. One of the issues that I ran into in my investigation was that the problem was closely tied to the structure of the data itself. My original OpenGL program only loaded .obj files at first. However, the process of converting the original .ive file to .obj disturbed the structure of the data, and caused the OpenGL program to behave differently. Unless I can load the exact data structure that OSG is loading into the VR Juggler example, I'm afraid I'd run into the same problem. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi, JP, On 01/26/2012 01:53 AM, J.P. Delport wrote: very interesting and thorough investigation. I can't really add anything and unfortunately don't have representative hardware to test on. It would be interesting to see if different bus configs (motherboards/chipsets) make any difference. The target hardware is a dual Xeon system with a 5400 chipset (the last chipset with a FSB) and a pair of QuadroPlex D2's. I've been working on an Alienware desktop with an X58 chipset and two GeForce 260's. One would expect that the X58 with its QPI interconnect would succumb to bus contention later than the 5400 (the specs say so, at least), but on the largest data set, it appears that the X58 is still having the scaling problem, while on the workstation, the bottleneck has moved elsewhere. I also would not rule out the NVidia driver doing silly things. I remember once looking at some of the glue code for the binary blob and seeing TLB flushes that caused a Xenomai kernel to fail ito timing in interesting ways. Have you tried OProfile to get some idea of time spent in the driver? I'm not familiar with OProfile. I'll take a look. Thanks for the reply! --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/26/2012 01:01 PM, Peter Kilpatrick wrote: Hello, This may be relevant: Memory Speed, QPI and Multicore http://www.masm32.com/board/index.php?PHPSESSID=afe5222fb85c769a44da28f1eb5d4b82topic=17296.0 Hi, Peter, So the lesson there is to ensure that your RAM is running at optimal timings before blaming the bus. I'll look into that, thanks! --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/26/2012 01:02 PM, Tim Moore wrote: That is what I found at the time of that thread, testing with some models supplied by NIST. Newer hardware is highly optimized for massive geometry. For the record, I don't think the problem is bus contention, but lock contention in the NVidia driver. The amount of bus traffic involved in the OpenGL command stream is tiny. Thanks for that. A couple of people have mentioned bringing this to NVidia's attention. We'll probably end up doing that. The key to OpenGL performance in the 21st century is reducing the number of OpenGL function calls to a minimum... so says Captain Obvious. I'm glad the mesh optimizers turned out to be useful! Yeah, once you get down to the data itself, it ends up being pretty obvious (5,500 draw calls runs slower than 9 draw calls? Really? :-) ). There was a bit of digging to do before we got to that point, though. At the outset, we originally thought that an OpenGL program wasn't showing the same problem that an OSG program was, which pointed the blame at OSG. Turns out that we weren't doing an apples-to-apples comparison with the data sets. It wasn't until we could get precisely the same set of data into the OpenGL program that we could start looking at the data itself as the culprit. Definitely a big thanks for the mesh optimizers. I was all set to start writing something myself, but then I realized they were already there :-) Btw, the Linux tool oprofile is mentioned later in the thread, but I find the newer tool perf to be more useful. Thanks, I'll check that out. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Request for input
to 8 fps on four screens vs. 11 fps on one. So, here are our questions. Does it make sense that bus contention would be causing the lack of scalability? Are the mesh optimizations mentioned above the most effective way to solve the problem? Are there any cases where the mesh optimizations wouldn't be sufficient, and additional steps would need to be taken (I briefly mentioned state changes above, which could be problematic, anything else)? Why doesn't the 64x data set seem to scale as well as the 1x and 8x data sets (does this indicate that the bottleneck has moved from the bus to somewhere else)? Any thoughts on these issues or other thoughts you could provide would be very valuable. Thanks, all! --J Jason Daly University of Central Florida Institute for Simulation and Training January 23, 2012 Running on Tylium: QuadroPlex D2 (four FX5800) export __GL_SYNC_TO_VBLANK=0 export OSG_SERIALIZE_DRAW_DISPATCH=OFF export OSG_THREADING=CullThreadPerCameraDrawThreadPerContext use ./run_1.6 ID Command From log files use collective times 1/23/2012 1/24/2012 FPS FPS FPS FPS ID Command line: pre-opt post-optpre-opt post-opt -- -- --- --- OSGa0 osgMultiCardOpt_v1.4 -e 60 -o 60 0 testex.ive 427.64 522.63491.82523.42 OSGa1 osgMultiCardOpt_v1.4 -e 60 -o 60 0 1 testex.ive 396.95 527.63362.84528.38 OSGa2 osgMultiCardOpt_v1.4 -e 60 -o 60 0 1 2 testex.ive 349.54 527.51358.56523.79 OSGa3 osgMultiCardOpt_v1.4 -e 60 -o 60 0 1 2 3 testex.ive 291.72 520.12306.78518.70 GLUa0 multithreadTest_v1.6 -t 60 0 testex.osg 708.58 707.98 GLUa1 multithreadTest_v1.6 -t 60 0 1 testex.osg 702.55 702.43 GLUa2 multithreadTest_v1.6 -t 60 0 1 2 testex.osg 602.16 596.58 GLUa3 multithreadTest_v1.6 -t 60 0 1 2 3 testex.osg 376.69 391.55 GLOa0 multithreadTest_v1.6 -t 60 0 testex.opt.osg 708.75 708.62 GLOa1 multithreadTest_v1.6 -t 60 0 1 testex.opt.osg 702.96 703.22 GLOa2 multithreadTest_v1.6 -t 60 0 1 2 testex.opt.osg 699.22 699.12 GLOa3 multithreadTest_v1.6 -t 60 0 1 2 3 testex.opt.osg 696.27 696.23 OSGb0 osgMultiCardOpt_v1.4 -e 60 -o 60 0 testex_2x2x2.ive 59.98 76.44 59.98 76.70 OSGb1 osgMultiCardOpt_v1.4 -e 60 -o 60 0 1 testex_2x2x2.ive 53.30 77.41 52.79 77.78 OSGb2 osgMultiCardOpt_v1.4 -e 60 -o 60 0 1 2 testex_2x2x2.ive 45.00 76.77 44.02 77.29 OSGb3 osgMultiCardOpt_v1.4 -e 60 -o 60 0 1 2 3 testex_2x2x2.ive 42.10 53.26 42.08 70.89 GLUb0 multithreadTest_v1.6 -t 60 0 testex_2x2x2.osg 107.89 107.88 GLUb1 multithreadTest_v1.6 -t 60 0 1 testex_2x2x2.osg 107.75 107.74 GLUb2 multithreadTest_v1.6 -t 60 0 1 2 testex_2x2x2.osg85.80 87.65 GLUb3 multithreadTest_v1.6 -t 60 0 1 2 3 testex_2x2x2.osg44.54 45.00 GLOb0 multithreadTest_v1.6 -t 60 0 testex_2x2x2.opt.osg 107.71 107.63 GLOb1 multithreadTest_v1.6 -t 60 0 1 testex_2x2x2.opt.osg 107.52 107.51 GLOb2 multithreadTest_v1.6 -t 60 0 1 2 testex_2x2x2.opt.osg 107.46 107.48 GLOb3 multithreadTest_v1.6 -t 60 0 1 2 3 testex_2x2x2.opt.osg 107.42 107.42 OSGc0 osgMultiCardOpt_v1.4 -e 60 -o 60 0 testex_2x2x2_2x2x2.ive 7.14 10.87 6.51 10.82 OSGc1 osgMultiCardOpt_v1.4 -e 60 -o 60 0 1 testex_2x2x2_2x2x2.ive 6.32 9.53 5.99 9.56 OSGc2 osgMultiCardOpt_v1.4 -e 60 -o 60 0 1 2 testex_2x2x2_2x2x2.ive 5.32 8.78 5.69 8.93 OSGc3 osgMultiCardOpt_v1.4 -e 60 -o 60 0 1 2 3 testex_2x2x2_2x2x2.ive 5.64 7.31 5.70 8.05 GLUc0 multithreadTest_v1.6 -t 60 0 testex_2x2x2_2x2x2.osg7.99 7.93 GLUc1 multithreadTest_v1.6 -t 60 0 1 testex_2x2x2_2x2x2.osg
Re: [osg-users] Request for input
On 01/25/2012 04:59 PM, Jason Daly wrote: Hi, all, This is a general request to the community for some advice and expertise. This is a bit lengthy, but if you can spare a few minutes to look over this and send along your thoughts, we would really appreciate it. I should also mention that the source code and data sets used in this work can be made available if anyone would like to try these tests on their own hardware. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Frame syncing over multiple contexts
On 01/20/2012 04:32 AM, Robert Osfield wrote: Hi John, On 19 January 2012 20:58, John Kelsoke...@nist.gov wrote: OK then! This is getting good! I tried setting setEndBarrierPosition(BeforeSwapBuffers), setting setThreadingModel(CullDrawThreadPerContext), and running with four windows, each with a single camera, on a desktop system with a single graphics card, and the problem didn't go away. But should the problem go away in this environment? Without swap ready and gen lock you can't perfectly sync the displays. swap ready is a signal that all the rendering on a graphics card has completed and is ready to swap. gen lock is a hardware sync of the refresh itself that ensures that the scan for each display occurs at the same time. This is four contexts on just one GPU and display, though. I don't think genlock/swap ready would come into play here. (glFlush/glFinish might, though) On a related note, does anyone know if the NV_swap_group extension mentioned earlier would work in the case of multiple contexts on one GPU/display, or does it only support synchronizing swap between GPUs/displays? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scene graph structure vs. performance question
On 01/10/2012 02:06 AM, Joel Graff wrote: The application isn't designed to create particularly large scene graphs, but it is a shader development tool. I can't really guess at the effect of a bloated structure, but I have the funny feeling it won't really matter. I also don't really know how flexible I may want my application node to be, but I see significant advantages to using the latter method and letting profiling after the fact bear out the bottlenecks. I think you're right. For your use case, I don't think a few nodes that are technically redundant will matter all that much. You can always streamline later if it becomes a problem, but I doubt you'll need to. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help:How to control rasterization stage through osg?
On 01/10/2012 02:55 PM, wang shuiying wrote: Hello, we know that in openGL rendering pipeline, there is a stage called rasterization after per-vertex operation and before per-fragment operation. In rasterization stage, openGl generates certain properties (e.g. texture coordinates)for each fragment as a linear function of the eye-space or object-space or windows space coordinates. My question is , how to check which coordinate is used in osg implementations? And how to change the coordinate that is used? The per-fragment attributes you're talking about are just interpolated from the same attributes that are assigned to the surrounding vertices. AFAIK, there's no way to change how these are computed, even with shaders (they're just simple linear interpolations). It sounds like you might actually be talking about TexGen (texture coordinate generation), which in the fixed-function world can be set to OBJECT_LINEAR, EYE_LINEAR, SPHERE_MAP, NORMAL_MAP, or REFLECTION_MAP. TexGen will automatically compute the texture coordinates on the vertices (which will then be interpolated for each fragment, as mentioned above). In OSG, the TexGen StateAttribute controls texture coordinate generation. If you're using shaders, it's up to you to do the texture coordinate generation math yourself. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help:How to control rasterization stage through osg?
On 01/10/2012 03:57 PM, wang shuiying wrote: So from your reply, only texture coordinates can be generated in different ways. As to general attributes, one has no way to change the interpolation method performed on them? I don't know of any way to change the rasterization behavior. As far as I know, that's still part of the fixed-function pipeline. I don't think there are even any parameters to control it, outside of the shade model, and anti-aliasing and multisampling parameters. Can I at least get to know, if can not change, the interpolation method used by the openGl in my implemention? Section 3.6 of the current OpenGL specification has all of the equations for this: http://www.opengl.org/registry/doc/glspec42.core.20110808.pdf --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help:How to control rasterization stage through osg?
On 01/10/2012 03:57 PM, wang shuiying wrote: So from your reply, only texture coordinates can be generated in different ways. As to general attributes, one has no way to change the interpolation method performed on them? I don't know of any way to change the interpolation functions used for rasterization. As far as I know, that's still part of the fixed-function pipeline. I don't think there are even any parameters to control it, Can I at least get to know, if can not change, the interpolation method used by the openGl in my implemention? Section 3.6 of the current OpenGL specification has all of the equations for this: http://www.opengl.org/registry/doc/glspec42.core.20110808.pdf --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help:How to control rasterization stage through osg?
On 01/10/2012 04:39 PM, Paul Martz wrote: Other sections too, 3.10.1 for example. Try searching the spec for centroid or noperspective; information on shader variable interpolation is scattered around in several places. I'd think simple linear interpolation could be accomplished using the noperspective qualifier: noperspective out vec3 eyeCoord; // for example ...but I haven't played with this. You might consider searching/posting at the opengl.org discussion boards. Good call, Paul. I don't remember hearing about the interpolation qualifiers. Those are covered in section 4.5 of the GLSL spec... http://www.opengl.org/registry/doc/GLSLangSpec.4.20.8.clean.pdf --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Exporting to SVG from OpenSceneGraph.
On 12/15/2011 11:37 AM, Chris 'Xenon' Hanson wrote: On 12/14/2011 9:31 AM, Jason Daly wrote: Actually, Jeremy Moles is working on a nodekit that uses nVidia's path rendering extension to OpenGL to render 2d vector graphics in 3d space. I believe the extension can read SVG files natively, so Jeremy's osgNVPR kit should be able to as well. But, I think that's the reverse of what he wanted to do, right? Probably. The OP asked whether one could render to vector SVG from OpenSceneGraph. I guess I read it too quickly and missed the to :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Exporting to SVG from OpenSceneGraph.
On 12/14/2011 09:26 AM, Jesper D. Thomsen wrote: Hi guys, I have a question regarding exporting to SVG from OpenSceneGraph. In our software product we use OpenSceneGraph for both a model view window and for a charting component. So far we have exported images from the charting component as bitmap images (by just rendering them to an offscreen pixelbuffer in the required resolution). We have however had some requests for exports from our charting component in a vector format compatible with the Microsoft Office software package (which pretty much means EMF files). Since EMF is very Microsoft-specific, I was thinking of using SVG as an intermediate format, and then using some converter package to create the EMF output. I saw SVG mentioned on the OSG mailing list earlier, but my question is whether there is any way to render to vector SVG from OpenSceneGraph (I kind of expect a hard “no” here)? Actually, Jeremy Moles is working on a nodekit that uses nVidia's path rendering extension to OpenGL to render 2d vector graphics in 3d space. I believe the extension can read SVG files natively, so Jeremy's osgNVPR kit should be able to as well. The relevant thread is here: http://forum.openscenegraph.org/viewtopic.php?p=42207 The down side, of course, is that you'll be limited to hardware that supports this extension, which is only the more recent nVidia cards (GeForce 8 and later), I believe. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg threading model
On 12/13/2011 01:47 AM, Vijeesh Theningaledathil wrote: Hi, Excuse me for posting this question as I'm just a beginner in the computer graphics. Which threading model will give the best performance in a dual core computer with Nvidia Quadro graphics card. The answer to that will depend on your application. If you're not sure, just let OSG pick the threading model for you (the default). Also I have a doubt regarding the makeRotate for camera rotation. If I use pitch,roll, yaw order, camera rotation doesn't work. I have to use roll , pitch, yaw order only. Why this is required? I'm not sure what you're asking. None of the makeRotate methods in osg::Matrix explicitly refer to pitch, roll, or yaw. The generic answer is that Euler angle rotations are not commutative (the order in which you apply the rotations is mathematically significant). Look here for more details: http://www.euclideanspace.com/maths/geometry/rotations/euler/index.htm or, better yet, just avoid them altogether: http://www.sjbaker.org/steve/omniv/eulers_are_evil.html --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Color in ShapeDrawable
On 12/02/2011 03:18 PM, Farshid Lashkari wrote: Hi Jason, On Fri, Dec 2, 2011 at 11:30 AM, Jason Daly jd...@ist.ucf.edu mailto:jd...@ist.ucf.edu wrote: I don't understand what you mean here. If you disable lighting, material colors are irrelevant. The ShapeDrawable's colors are the ONLY way to set the color. That's actually not the case with OSG. If you look at the source for osg::Material, you will notice it calls glColor with one of the material colors (depending on the color mode). This means you can use osg::Material to control the color of geometry even when lighting is disabled. My mistake, I didn't realize that. I guess I've never hit that use case before. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] cdash site down
Just happened to notice that cdash.openscenegraph.org is unreachable from here (Orlando, FL, USA). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Menus and Dialog Boxes
On 11/18/2011 02:36 PM, dan marshal wrote: Hi, I did a search of this forum, and have not seen anything yet in osg docs to suggest how to add a basic menu or dialog box to an osg application. Short of trying to tie osg with qt does anyone have a simple way to open a file dialog, or simply to change settings? I would like to stay within the osg framework if possible. What are you using? Is there an osg example with a menu or dialog? Maybe I have not seen it... OSG isn't really a GUI library. There is basic support for on-screen widgets in the osgWidget nodekit, but it's probably not as full-featured as you're hoping. Most folks that do what you're looking to do use OSG with an external toolkit, like Qt or GTK+. There are OSG examples for integrating with Qt and GTK+, so you might want to have a look there. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency Bin Default Behavior
On 11/08/2011 04:26 PM, Buckley, Bob CTR MDA/DES wrote: I just found that the transparency bin does not disable z writes by default. Is there a way to do this via the existing API? Pre-traversal callback? Mode? Attribute? I’ve been looking thru the archives and see only one reference. Indeed cites it as the solution. Hi, Bob, Something like this should work... depthAttr = new osg::Depth(); depthAttr-setWriteMask(false); stateSet-setAttributeAndModes(depthAttr, osg::StateAttribute::ON); --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency Bin Default Behavior
On 11/08/2011 04:51 PM, Buckley, Bob CTR MDA/DES wrote: Hey, Jason. Was just down in your neck of the woods, kinda – flying @ Sebring. I got the per state solution. But, I’m looking for fixing the transparency bin. Should be on that bin rather than wasting resources on identifying and setting on all the applicable states – transparent colors and textures. Hmm. You can set a StateSet on a RenderBin, but I'm not entirely sure if that would accomplish your goal or not. It's also a bit of a pain to get to the RenderBin objects from the Viewer, but I think it's possible: viewer.getRenderer().getSceneView(0).getRenderStage().getRenderBinList(). find(osg::StateSet::TRANSPARENT_BIN); The Renderer has two SceneViews for double-buffering, so you'd have to do this on both. Hopefully someone will correct me if this is totally wrong :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer/CompositeViewer inconsistency?
On 11/01/2011 12:17 PM, Thomas Lerman wrote:
Yeah, I have been looking at the source code quite a bit lately trying to get
these things to work. I am not really sure what your are saying about the
following method:
Code:
int Viewer::run()
{
if (!getCameraManipulator() getCamera()-getAllowEventFocus())
{
setCameraManipulator(new osgGA::TrackballManipulator());
}
setReleaseContextAtEndOfFrameHint(false);
return ViewerBase::run();
}
The last line is the key. Viewer::run() calls ViewerBase::run(). If
you look at ViewerBase::run(), you'll see that it calls
ViewerBase::frame() in a while (!_done) loop (along with some other
ancillary stuff to handle on-demand rendering, run-to-frame control,
etc). So, you could, in fact, write your own run loop like this:
while (!viewer.done())
{
viewer.frame();
}
If you need more control than that (which it sounds like you do), you
can look at ViewerBase::frame(). ViewerBase::frame() couldn't really be
much simpler. Essentially, it is just:
advance();
eventTraversal();
updateTraversal();
renderingTraversals();
You probably don't need to mess with the advance() step, or the
renderingTraversals() call, so you can just look into the event and
update passes to see where you might need to make some adjustments.
Hopefully, this will help get you going in the right direction.
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] transparency is hard! Drawing order of drawables inside a Geode?
On 10/26/2011 02:35 PM, Christian Buchner wrote: Are there any insights for rendering transparent stuff from the OSG community? Are there proven approaches to rendering transparency correctly for objects? Hi, Christian, You might want to look at the osgdepthpeeling and/or the osgoit examples. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Segfault with Qt
On 10/25/2011 02:15 AM, Tiziano Müller wrote: Hi Jason Well, I tried once with the nvidia-drivers as well and I got a segfault in libGL instead, but I will try again. My mistake. I didn't catch that in your original message. Sometimes I read too quickly :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Segfault with Qt
On 10/22/2011 09:09 AM, Tiziano Müller wrote: Hi everyone I am using OpenSceneGraph-3.0.1 for a little project together with Qt-4.7.4 and it worked perfectly. After same updates on my system (I can't figure out what exactly changed) I get segfaults when starting either my app or the osgviewerQt demo. Hi, Tiziano, It looks like you're using the open-source Nouveau drivers that come with Fedora. These drivers are in a constant state of development. From the Nouveau FAQ: nv50 and nvc0 On February 28th, 2011, the original nv50 Gallium3D driver was completely replaced (in git) by the nvc0 Gallium3D driver ported to NV50 family of cards. These drivers are included in *Mesa 7.11*. For nvc0 and the new nv50 drivers, you have to use *at least the 2.6.38 kernel* or you will encounter memory corruption. Bug reports for nv50 and nvc0 can be submitted by following the general reporting guidelines http://nouveau.freedesktop.org/wiki/Bugs. Please, also follow the /About bugs and problems/ section above. If you want things to function reliably, you should probably install the proprietary Nvidia drivers from http://www.nvidia.com. Otherwise, it'll be up to you to deal with the normal issues of unstable open-source software. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Handover textures to OSG from opengl/opencl
On 10/18/2011 02:35 PM, Christophe Herreman wrote: Anyone? Is it impossible to handover textures to OSG ?? I don't understand what you mean by handover textures to OSG. Can you explain what you're trying to do in more detail? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image formats, most efficient?
On 10/13/2011 05:58 PM, Thomas Lerman wrote: It appears the native OSG formats include: a) Text formats: .osg .osgt b) Binary formats: .osgb .ive I know the text formats are much larger and slower to load. In my case, the binary formats are exactly the same size. So, I am curious what the differences specifically between the binary formats? The .ive format was the original binary format for OSG. It is not extensible, so the binary format must be altered as new objects are added. The .osgb format is a newer, extensible format that makes use of serializers to store OSG objects in the file. All three formats .osgt (text), .osgb (binary), and .osgx (XML) use the same serializers, so the newer extensible formats are easier to maintain. What is the fastest format to load manipulate (really only scale, orient, translate)? I would presume that one of the OSG native binary formats would be the best to use. Correct, the native binary formats will be much quicker to load than any other format. It's probably a toss-up between .ive and .osgb at this point. The .osgb format is the way forward, though a lot of people still use .ive. I realize my model is quite complex, so I am using osgconv to convert and reorient it. I tried scaling and compressing, but neither had an effect to the size. When I tried simplify, it did reduce the file size, but osgviewer crashes when I try to view the resulting image. Am I doing something wrong or is the model just too complex? In general, scaling isn't going to reduce the size of the file. Compressing it (with zip or gzip, for example) will probably make the file smaller, but you'll have to decompress it to use it, even if you use the .zip plugin to decompress it into memory. In general, simplifying the model will reduce the overall size of the file. You don't say how you went about simplifying it, so I can't really determine why that's causing a crash. It sounds like the simplification process caused one or more of the objects in the resulting file to be invalid. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
On 10/12/2011 09:55 AM, Wojciech Lewandowski wrote: I have prepared a modified osgViewer source which can be used to reproduce the bug (run it without args). See attached screenshots for correct and incorrect output. I will be grateful for some feedback on this issue... Hi, Wojtek, RHEL 6.1 NVIDIA GTX 260 driver version 285.05.09 I get the good result. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgParticle variables causing objects to disappear
On 10/05/2011 07:26 AM, Simon White wrote: Not to worry, I redesigned the min and max values to give a better looking fire, and now the problem has gone. Still don't know what caused it though, gonna worry about that in the future D: Your problem might have been caused by small feature culling. You can try disabling it: mode = camera-getCullingMode(); camera-setCullingMode(mode ~osg::CullSettings::SMALL_FEATURE_CULLING); --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text heap corruption when using setText()
On 09/19/2011 11:44 AM, Joshua Cook wrote: So, I would like to know if a) I'm using the Text object correctly or if there is something else I should be doing to make it thread safe for a text update and b) if I'm using the Text object correctly then is this a known bug and do I need to submit a bug report. You might try setting the data variance of your text objects to DYNAMIC. text-setDataVariance(osg::Object::DYNAMIC); This method is inherited from osg::Object, and informs the scene graph that the data might be changing on the fly, so it should double-buffer it between the update and cull/draw phases. If that doesn't fix it, you might have found a genuine bug. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to set DOFTransform?
On 09/19/2011 02:55 PM, Paul Martz wrote: Now I want to create an osgSim::DOFTransform ( http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00182.html ) to describe this DOF. Unfortunately I do not exactly what I have to do now. The DOFTransform neither has a setPosition() nor a setAxis() method. Do I have to use setPutMatrix()? If yes: How do I create this matrix? Is it just M = RotationY(90) * Translation(DOFPosition)? Do I also need to set the Inverse PutMatrix? The short answer is yes, you need to use the Put and Inverse Put matrices. The put matrix should translate the origin of the DOF to the local origin and align the axes correctly. The inverse put should do the opposite, that is, it should literally be the inverse of the put matrix. For the complete explanation, see the OpenFlight spec that Paul mentioned. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 11:03 AM, Mik Wells wrote: However the Y-up OpenGL default is still relevant. What page of the OpenGL spec specifies that the default coordinate system is Y-Up? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 01:23 PM, Mik Wells wrote: Hi, As far as I know it's not explicitly specified but is implicit in the projection transforms. Assuming the ModelView matrix is the identity, the matrices generated by the traditional Ortho/Frustum functions would result in a vertex's Y value determing its height on the screen. That scenario is enough for me to adopt Y as the natural up axis. The point is that the x-right, y-up convention has nothing to do with OpenGL. It comes from the transformation from world space to screen space. The 2D screen is where the x-right, y-up comes into play. If you adopt a right-handed coordinate convention (which you don't have to, but it makes certain things in OpenGL more convenient), then the identity modelview and projection matrices will give you a projection where x is right, y is up and Z is toward you (out of the screen). Some window systems might even tack their own transform onto the end of this (XRandR, for example will change the x-right, y-up convention so you can rotate your monitor). Paul's original point is that nothing in OpenGL is enforcing this, and once you start manipulating the modelview and projection matrices, it doesn't really mean anything anyway. There's no reason to pay any attention to the default orientation, since you can change that with a simple transform concatenated into the dozens of transforms you're already doing anyway. There are no absolutes when it comes to coordinate systems, everything is relative. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 03:01 PM, Mik Wells wrote: This isn't quite true as the projection matrix (which determines X-right, Y-up, Z-out) is non-invertible and so can't be treated as just another transfom in the stack. I don't see what that has to do with my statement. My point is that adding another transform isn't difficult, and doesn't cost anything. Invertible or not, it's still just another matrix. Also, the projection matrix doesn't determine X-right, Y-up, Z-out any more than any other transform does. You can change what's up/right/out in the modelview just as easily. Indeed, in the brave new world of shaders, the projection and modelview matrices really don't even exist anymore. All that matters is what you do with your vertices in the vertex program. I think the salient point is that Matrix_implementation::getLookAt() uses Y-up (the up-vector is (0,1,0). Sure you could rotate the OpenGL projection matrix to allow getLookAt() to use Z-up but I've never seen this happening in the wild and it would only serve to confuse. The only reason OSG does that is because the window system uses the Y coordinate as the vertical axis of the screen, and OSG made the design decision to follow that. Again, none of this has anything to do with OpenGL. OSG could have just as easily used Z as the up vector, and the osg::Camera would be following a Z-up convention. Sure, there would need to be another transform internally to get the what GL draws to line back up with the window system, but that's trivial. The point of this whole thread is that there is no reason to worry about what is the natural direction of up. It makes a lot more sense to adopt a coordinate system that works best for you application because getting OpenGL/OSG/whatever to follow that convention is trivial. For example, most of the terrain databases in our simulators are relatively small and use a convention that X is east, Y is north, and Z is up. This isn't OpenGL's natural orientation, but how often do we worry about that? Never! We don't even do any kind of camera transform to handle it. The databases are modeled Z-up, so our camera just implicitly inherits the Z-up convention. When we want to move the camera up, we increment the Z coordinate and it just works. Everything is relative. Larger simulations need to use whole-earth databases which will pick a convention where the origin of the world coordinate system is the center of the earth, the X axis projects out the prime meridian and the Y axis is 90 degrees east (or something similar). Near the surface of the earth, the orientation isn't even axis aligned, but it really doesn't matter, because it's just another transform. Worrying about what OpenGL implicitly calls up is not useful, it's limiting. Worry about what your application would prefer to call up instead. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 03:59 PM, Mik Wells wrote: Hi, It isn't the window system (e.g. Microsoft Windows) which uses the Y coordinate as the vertical axis of the screen. It's OpenGL. (On my windowing system Y is down). That is accounted for in the viewport transform, not inside OpenGL itself. Worrying about what OpenGL implicitly calls up is not useful It may not be useful at the app level, but it's essentail if you're trying to calculate the up-vector. The up-vector is a relative concept. It doesn't mean anything on its own. Invertible or not, it's still just another matrix The projection matrix has a very different role to the ModelView matrix, which is one reason why it has its own matrix stack. That doesn't mean it isn't just another matrix. It's certainly useful and advisable to separate them conceptually, but nothing forces you to do so. In OpenGL 3.1+ (core profile) there isn't even a glMatrixMode() anymore (or a glMatrix-anything for that matter). You just do whatever you want in your vertex shaders. If you wanted to, you could calculate a separate projection for each vertex and then move them all around in clip space. It would be ugly, sure, but there's nothing stopping you. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 04:33 PM, Paul Martz wrote: You're free to put whatever transform you want in either matrix as long as transform by the two produces clip coords, but for correct FFP lighting computations, your modelview matrix *must* produce eye coordinates. OpenGL FFP lighting is computed in eye space. So, if you did something crazy like have an identity modelview, but a full object-to-clip transform in the projection, then vertices would be transformed correctly, but your lighting would be way wrong. You're right, Paul, I neglected the FFP lighting issue. There is a fundamental difference between the projection and modelview transforms for this purpose, and since lights are in eye space, there is an inherent coordinate system as well, so I stand corrected on those points. Still, in OpenGL 3.1+, that's all out the window :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG static linking for commercial application
On 09/14/2011 01:36 PM, Aurelien Albert wrote: Hi, This is a question about legal statement, not technical. I'm working on a commercial project based on OSG. I made a dynamic library 3dstuff.dll with all my 3D stuff, this DLL uses OSG. Can I use static linking of OSG with my 3dstuff.dll to distribute only this DLL with my executable file ? Or is it an OSG license violation and I have to distribute OSG as a set of dynamic librairies ? (osg.dll, osgGA.dll, osgXX.dll ) I ask this question here because I found this : The OpenSceneGraph Public License is designed to be compatible with use of proprietary applications, such applications can statically and dynamically link to the OpenSceneGraph and can be redistributed with the libraries free of charge. Your applications can be distributed under any license, be it open source or proprietary. at http://www.openscenegraph.org/projects/osg/wiki/Legal which seems to say ok, you can do that But in the complete license text, here : http://www.openscenegraph.org/projects/osg/attachment/wiki/Legal/LICENSE.txt I didn't find anything about static linking. The relevant text is in the wxWindows exception #2 near the top: 2. The exception is that you may use, copy, link, modify and distribute under the user's own terms, binary object code versions of works based on the Library. Meaning that you are not required to distribute your own source code when you link it against OSG (either statically or dynamically). This is provided that you don't copy any code into OpenSceneGraph or your own code that is licensed as LGPL or GPL-only (as stated in exception #3). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] iOS: wireframe
On 09/02/2011 08:56 AM, Paul Martz wrote: I suspect glPolygonMode is not supported in any flavor of OpenGL ES. http://www.khronos.org/opengles/ ...but you should check the spec. Paul's right. I checked the spec. glPolygonMode is not supported by OpenGL ES. That was a surprise to me as well. It is still part of the core profile in OpenGL 3.1 and higher. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unable to load osgdb_tiff plugin on CentOS 5.6
On 09/02/2011 04:30 PM, Cary, Karl A. wrote: I just confirmed that it happens with all tiffs, not just geotiffs. I created something in gimp and used that. Worked in 5.5, not in 5.6. I honestly have no idea what to do other than to roll my own custom tiff loader, which I don't have time to do as it has to be done today. What do you see if you run ldd on osgdb_tiff.so? Does it point to the libraries that you expect? From your description, I doubt this will be the issue, but it's all I can think of at the moment. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Density of the SmokeTrailEffect
On 08/31/2011 02:16 PM, Brad Colbert wrote: Hi folks, I have a simple rocket model with a SmokeTrailEffect added and the trail is more like a train of puffs. How do I control the density or closeness of the puffs to make it look more like a trail? The SmokeTrailEffect's ModularEmitter object has a parameter that you can tweak to compensate emission rate for movement rate. I've not used it myself, so I don't have any advice on how exactly to adjust it. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeCallback
On 08/03/2011 04:58 AM, Martin Haffner wrote: Ok, but what do these 4 types exactly mean? I guess a PreDraw callback gets called BEFORE the camera renderes and PostDraw AFTER the camera has been rendered its subtree. But what means Initial? And whats the difference between PostDraw and Final? You can see how the process is carried out by tracing through the code in osgUtil::RenderStage::draw(). Essentially, the Initial callback is called before any of the camera's pre-render stages are run, while the PreDraw callback happens immediately before the camera's own scene is drawn. Similarly, the PostDraw callback happens immediately after the camera's own scene is drawn, and the Final callback happens after any post-render stages are drawn. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shader problem: texture2D() multiplying with textureCube()
On 08/02/2011 05:35 AM, Joe Abreu wrote: hybr wrote: Seems like you mess up sampler uniforms setup. You unit declared as unsigned int, and osg uses different gl functions to set uniform with int and unsigned values (which is right thing), and samplers uniforms must be set with signed int version. So just cast it to int when use uniform-set(sampler) or redeclare as signed integers. You sir, are a legend. Thanks! Wow, that's subtle. Good eyes, Sergey! --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeCallback
On 08/02/2011 07:44 AM, Martin Haffner wrote: Hi, Guys, you are great! Thanks to both of you for your good explanations! :D Another little question: I guess a Camera::DrawCallback is a callback that gets added to a osg::Camera and that gets called (operator()) every time the camera renders the scene? Correct. Also, note that there are four different places to attach Camera::DrawCallbacks (Initial, PreDraw, PostDraw, and Final). Which one you use will depend on what you're doing in the callback. For example, a FinalDrawCallback is a good place to capture the image of what the camera just drew. This is what the osgscreencapture example demonstrates. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeCallback
On 08/01/2011 11:05 AM, Martin Haffner wrote:
Hi,
I have problems with understanding the use of a NodeCallback.
Can anyone explain me what a Nodecallback is doing?
A NodeCallback is a class that implements a method ( operator() ), which
is called when a particular traversal (update, cull, draw, event, etc)
reaches that node in the scene. These traversals are run every time a
new frame is drawn.
Another concrete question:
I have some code with a class that derives from osg::Nodecallback. This class
implements operator():
Code:
class CameraUpdateCallback : public osg::NodeCallback {
private:
osg::ref_ptrosg::CameramOtherCam;
public:
CameraUpdateCallback(osg::Camera* otherCam) : mOtherCam(otherCam) { }
osg::ref_ptrosg::Cameram_sourceCamera;
void operator()(osg::Node* node, osg::NodeVisitor* nv) {
osg::Camera* cam = static_castosg::Camera*( node );
cam-setViewMatrix(mOtherCam-getViewMatrix() );
cam-setProjectionMatrix(mOtherCam-getProjectionMatrix() );
traverse(node , nv);
}
...
camera-setUpdateCallback( new CameraUpdateCallback( currentView-getCamera() )
);
While I don't really understand the purpose of this code, I can tell you
that this is defining a callback that seems to be setting the view and
projection matrices of an osg::Camera (camera) to be equal to those of
another osg::Camera (otherCam). The callback is attached to camera and
will be run during the update traversal ( setUpdateCallback() ).
NodeCallbacks and traversals are fundamental operations of OSG (and most
other scene graphs as well). If you aren't grasping them from my brief
description, I'd recommend checking out the OSG Quick Start Guide, which
explains them in a bit more depth.
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shader problem: texture2D() multiplying with textureCube()
On 08/01/2011 11:44 AM, Joe Abreu wrote: One more point to add onto the problem is that I guess the actual problem is that in the debugger I receive the message: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) Is there any way to actually working out what is causing this error, it only every occurs if in any combination of GLSL code the texel of a textureCube is any in way blended with a texel of a texture2D. Even the following statement doesn't work. What hardware are you running on? It's almost as if you don't have enough texture units (i.e.: more than one) to handle the operation... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shader problem: texture2D() multiplying with textureCube()
On 08/01/2011 12:04 PM, Joe Abreu wrote: I'm running a NVidia GeForce GTX 460 on my i7 machine, I've done plenty of other shader stuff before with multiple textures, for some reason in this example I'm running it just isn't working. It's the first time trying to link to OSG 3.0.0, but I've tried linking back to the previous version of open scene graph I was using (2.8.3) and it still doesn't work. Yeah, that should definitely be enough (not that that's saying much, a GeForce 3 from 2001 would be enough...) Hmm, only other thing that comes to mind is the two sampler uniforms. Are they set to different values in the CPU code? That's all I can think of... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shader problem: texture2D() multiplying withtextureCube()
On 08/01/2011 01:43 PM, Jason Daly wrote: Yeah, that should definitely be enough (not that that's saying much, a GeForce 3 from 2001 would be enough...) Hmm, only other thing that comes to mind is the two sampler uniforms. Are they set to different values in the CPU code? That's all I can think of... Never mind, I see you already mentioned that they are in a previous post. Sorry, I'm stumped :-/ --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shader problem: texture2D() multiplying with textureCube()
On 07/29/2011 11:42 AM, Joe Abreu wrote:
Hi,
I have a problem that I have got my mind stuck at working out what is going
wrong. I have a simple vertex and fragment shader I am trying to test. which
look as follows:
vertex:
Code:
varying vec3 normal, eyeVec, reflectVec;
void main()
{
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_Position = ftransform();
normal = normalize(gl_NormalMatrix * gl_Normal);
eyeVec = vec3(gl_ModelViewMatrix * gl_Vertex);
reflectVec = reflect(eyeVec, normal);
};
fragment:
Code:
varying vec3 normal, eyeVec, reflectVec;
uniform sampler2D diffuseMap;
uniform samplerCube reflectionCube;
void main()
{
vec4 diffuseColor = texture2D(diffuseMap, gl_TexCoord[0].st);
vec4 reflectionColor = textureCube(reflectionCube, reflectVec);
gl_FragColor = diffuseColor * reflectionColor; //-- This is my offending
line
gl_FragColor.a = 1.0;
}
Hi, Joe,
Just a shot in the dark (all I've got time for, sorry). What happens if
you try this:
gl_FragColor.rgb = diffuseColor.rgb * reflectionColor.rgb;
gl_FragColor.a = 1.0;
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixing Z-Fighting in Far Field...
On 07/29/2011 03:52 PM, Oren Fromberg wrote: Howdy everyone, I have objects under a group node called Objects that are rendered. When the objects get too far away, Z-fighting occurs. Would it be possible to fix the Z-fighting by instead of adding the objects as a child of Objects, create two camera nodes as children to Objects (farCam and NearCam) and adding the objects to either camera based on its range to the eyepoint? the farCam and nearCam would be identical except zNear and zFar for the projection. Would I need to make any additional settings in the cameras for this to work? Hi, Oren, Sounds like you want to look at the osgdepthpartition example. What you're talking about is possible, but it may be a bit more complex than you're thinking. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking objets
On 07/28/2011 11:31 AM, Carlos Sanches wrote: Hi ! I m trying to detect wich object is selected with LineSegmentIntersector . I m using the example osgpick to help. The problem is that I can only see where the line is intersected but I want to execute some command only if a test objet is intersected. For example if I have two spheres A and B . How do I know if I m touching only the A sphere ? The osgpick code demonstrates how to get all kinds of information from the Intersection objects in the osgUtil::LineSegmentIntersector::Intersections list. You can get the local and world coordinates, the model matrix, the drawable object, the primitive index of the drawable, and even the node path traversed through the scene to get to the drawable. It's all in the Intersection object. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to judge the model renderering progress is over in my codes
On 07/27/2011 08:46 AM, ramy panda wrote: Hi, Now i have a problem in my codes that i want to get a large number of thumnail picture of the models. But i don't know when the model renderer progress is over and the model is show in the OSG viewport, because until the model renderer progress is over and model is show in the osg viewport in my codes i capture the thumnail picture of the model. Is there any one can help me with this problem. I'm in a hurry. Thank you very much! The osgscreencapture example should be a good starting point. Essentially, you'll want to use the Camera's FinalDrawCallback to capture your thumbnail image. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading textures into VRAM
On 07/27/2011 02:48 PM, Frank Sullivan wrote: Greetings, My understanding is that most OpenGL implementations will not load a texture into VRAM until the time that it is first used. I was wondering, will a call to glBindTexture suffice for using a texture? If so, could I write a node visitor that just visits every StateSet in my graph, pulls out the texture objects, and calls Texture::TextureObject::bind()? I'm trying to think of a way to preload all of my textures into VRAM so that I don't get a frame rate stutter the first time one object or another comes into view. Hi, Frank, I'm not positive, but the osgUtil::GLObjectsVisitor may already do what you need (look at the COMPILE_STATE_ATTRIBUTES mode). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to use CameraView
On 07/27/2011 06:01 PM, Robert Kern wrote: I just need to change the fov to match the specs of the HMD I am using for a virtual reality application. All you should need to do is call setProjectionMatrixAsPerspective() on each camera. The FOV you know, the aspect you can compute from the HMD's resolution (horizontal/vertical). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to use CameraView
On 07/27/2011 06:17 PM, Jason Daly wrote: On 07/27/2011 06:01 PM, Robert Kern wrote: I just need to change the fov to match the specs of the HMD I am using for a virtual reality application. All you should need to do is call setProjectionMatrixAsPerspective() on each camera. The FOV you know, the aspect you can compute from the HMD's resolution (horizontal/vertical). I should emphasize that the FOV passed to that method should be the vertical FOV. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT into a single color channel
On 07/14/2011 10:08 AM, Bolstad, Mark wrote:
I like the idea of combining the passes into one, but if I had a blue
object and had to mask it into the red channel, wouldn't it just be black?
Yes, it would be black on the red and green passes, but it would show up
on the blue pass. When you combined the three passes of the image to an
RGB texture, you'd have your blue object. The flow would look something
like this:
- set the camera to draw to an RGB texture
- set camera's color mask to red only
- draw the first object
- set camera's color mask to green only
- draw the second object
- set camera's color mask to blue only
- draw the third object
- fetch the texture from the camera and use it however you need it
as J-S said, you save the combine pass and you don't even need any
special shader magic.
I had talked to a professor who had suggested a one-line fragment
shader to do RGB- Luminance and use Color Masking to write into the
appropriate channel. Would rendering straight into a Luminance texture
with Color Masking work?
Maybe I'm not understanding you correctly, but I don't think this would
work. You'd end up with a luminance image (effectively, a grayscale
image) at the end and not a color image.
In reality, this is actually more complicated in that it's not three
objects, but three separate frames of animation. So the main loop is:
while(1)
{
advance sim
frame(); // Render to red
advance sim
frame(); // Render to green
advance sim
frame(); // Render to blue
Render RTT texture to display.
}
Maybe if you explained what you're trying to do at a higher level, we'd
be able to better help. What is the problem you're trying to solve?
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GPU Data Access
On 07/11/2011 11:47 AM, Martin Großer wrote: Hello, I have written a little application, which renders a scene into a texture. I use the frame buffer object, but my problem is, I need the data on the cpu after the rendering. I know that is the bottleneck, but I hope someone can give me a clever tip how I can do this without big delay. Maybe, is it possible to get access to the texture via a cuda program. Then I can do my procedure on the gpu and then I only transport the result back to the cpu? My procedure is quite simple. I have a depth map and I want to get the sum over all pixel values. OpenCL 1.1 has methods to exchange GL Textures and CL Image objects (i.e.: you can use an OpenGL texture as an OpenCL image object inside a CL program). To do this, you'd use the clCreateFromGLTexture2D() function in your OpenCL program. I've not done this myself, so I can't give you any code or specifics, but I do know that it's possible. I imagine that the latest CUDA version has similar functionality. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with UV Textures in OSG
On 07/07/2011 03:02 PM, Jordan Sparks wrote: We originally exported it to OBJ format considering I work on a mac and there is no mac exporter for OSG. What is this Wavefront OBJ? Is that just another name for OBJs or is that another thing altogether? They're referring to the same thing. The OBJ format was originally used by Wavefront Technologies' Advanced Visualizer animation software (one of the forerunners of Alias|Wavefront Maya, now Autodesk Maya), hence the term Wavefront OBJ. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] possible OSG 3.0.0 regression - different handling of transparencies in DDS texture loader?
On 07/06/2011 01:32 PM, Christian Buchner wrote: Hi, I've just tested our app against OSG 3.0.0, mostly because it has some rudimentary Multitouch support which I hope to extend on. During the upgrade we only stumbled across a renamed header file (MatrixManipulator to CameraManipulator). No big deal - some extra preprocessor macros in the code fixed that. My application features some hundred or thousand walking persons (implemented as animated billboards) that read their texture data from a DDS file. It seems handling of transparencies has changed though. Where previously the billboards had a transparent background, the walking persons now appear in inside solid black squares. So the entire billboard is opaque. Would anyone know if there was a breaking change in the DDS plug-in between OSG 2.8.2 and 3.0.0 regarding transparency handling? Before I start digging into documentation, maybe someone here knows. It most likely has to do with this thread: http://forum.openscenegraph.org/viewtopic.php?t=8168 Briefly, there was some confusion on how DXT1 files with alpha were detected and handled. My original fix was to assume that all DXT1 blocks with a particular bit pattern were transparent. However, another (arguably more complete) interpretation is that the bit pattern means either transparent or black, with the deciding factor being the image format. This is the behavior that Robert has now implemented. Of course, the .dds format header doesn't identify the image format completely, so it's not really possible to distinguish between DXT1a and DXT1c in a .dds file. In short, there are a new set of options that will let you alter the behavior to work with your data. You probably want to use the dds_dxt1_detect_rgba option. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation and official Kinect SDK
On 07/06/2011 08:38 AM, Aitor Ardanza wrote: I'm confused ... not sure if xna and osg use the same axes (xyz or xzy). getBoneMatrixFromKinectNuiControl give me a local rotation matrix, but do I need to change these to global? I know that in pBoneUpdate.at (i) - getStackedTransforms (). Push_back (new osgAnimation: StackedQuaternionElement ( rotate boneMatrices [i] - getMatrix (). getRotate ())); I have to apply a local array... but I guess I missed something, because the rotations are no goods in the model. I haven't touched the Kinect SDK, so I don't know for sure, but I have worked with DirectX in the past, and the coordinate systems between DX and OpenGL are quite different. Microsoft historically has used a left-handed coordinate system for all of its coordinate frames, while OpenGL, and hence OSG, is right-handed. Beyond this, there's also a good chance that the base coordinate systems at each joint aren't what you're expecting. The best approach would probably be to start with a simple one-joint model (if possible), and get that working properly first. Then, you can generalize that to the whole body. Sorry I can't give you any specifics, but I thought I'd say something since there hadn't been any replies yet. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Absolute beginner questions
On 06/09/2011 01:03 PM, basil huffman wrote: Ok, I deleted the build folder and restarted with the method you listed above and I am still getting massive amounts of errors (including the cannot find *.lib). Here is what I am doing: -downloaded OSG 2.4.8 zipped file, extract to D: and rename it OpenSceneGraph (i.e. D:\OpenSceneGraph) I assume you mean 2.8.4 (not 2.4.8). If you are using 2.4.8, that might explain a few things :-) Nothing you did sounds too out of the ordinary, though the red fields you mentioned don't sound right. Can you send a screen shot of the CMake window after you've plugged in the values for ACTUAL_3RDPARTY_DIR, etc? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performace issue with nVidia 400 series
On 05/19/2011 12:07 PM, David Glenn wrote Well I'm using a far chunk of terrain that is very texture based and I haven't seen any issues. Maybe I'm making a mistake getting the 460's and sould try the GTX 280. By texture-based do you mean you're reading the texture image from the GPU back into your application, or you're just using the texture data on the GPU for rendering. Unless you're reading the texture data back from the GPU (glReadPixels(), glGetTextureImage(), PBO in READ mode), you won't see the problem. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performace issue with nVidia 400 series
On 05/18/2011 05:14 AM, Fred Smith wrote: Hi, The only problem that I personally heard about is about the slow transfer speed to/from GPU memory on Fermi cards. DMA transfers are said to be slower than on GTX 2xx hardware. I haven't seen anything related to computing. I think it's specifically GPU-host memory transfers that are slow. The other direction is OK, as is the computation speed. The thread on the OpenGL forums has the details, and someone posted a small program that does timing tests and illustrates the issue pretty well. http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=284065page=1 --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performace issue with nVidia 400 series
On 05/17/2011 11:36 AM, Michael Rohn wrote: Is there a known issue? I searched the board but I had no success. The problem is also present on a nVidia GTX480. Look at the links on the Wikipedia page (especially the link to the OpenGL forum discussion). I haven't seen any official statement on the issue from nVidia, but the conjecture on the forums seems to be that it's a deliberate throttling of performance to create a product line separation between the GeForce gamer cards and the Quadro professional cards (Quadro cards are priced many times higher than the comparable GeForce product). Traditionally, games haven't needed quick pixel readback as much as other applications (GPU-heaving computational or scientific applications), so nVidia seems to be making it a professional feature and charging a premium for it. As the article mentions, you can get around it using CUDA code (and possibly OpenCL code as well), although that's obviously not a real solution. There seems to have been a bit of an uproar about this, so it remains to be seen if nVidia will address this issue or not. I suspect if enough people jump ship and start buying AMD cards, they might give it more attention. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build UserInterface
On 04/15/2011 01:22 PM, ahmed salah wrote: ya i am using OSG 1.2 for some compatibility reasons with other tool is there anything like OSGWidget in older versions ? No. You'll have to use a 3rd party toolkit. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.4-rc3 now tagged
On 04/06/2011 10:43 PM, Chris 'Xenon' Hanson wrote: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.4-rc3 This is intended to be the final 2.8.4. It now builds successfully on VS2010, and the ffmpeg changes Robert put in have been tested on Windows. We need testing on all platforms to call this one done. Please test and let us know your results. This won't get out until people step up and test. RHEL 6 looks good, including ffmpeg. I do have to finesse osgmovie into using the ffmpeg plugin for loading and playing .mov and .avi files (possibly others, but that's what I tested). I either have to LD_PRELOAD osgdb_ffmpeg.so, or specify -e ffmpeg on the command line. I expect this is known behavior, but I just wanted to make sure. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Y up to Z up
Yeah, I remember that feeling of elation when the coordinate systems finally lined up and started behaving :-) Nice work! --J On 04/05/2011 11:15 AM, Raymond de Vries wrote: Congrats, Aitor! You must be a happy man! :-) On 4/5/2011 5:03 PM, Aitor Ardanza wrote: Ok, I got it! All my problems were on the orientation of the bones in the model... Now, the avatar is animated well, though a bit slowly ... I will need a more powerful graphics card! I'll post here a small guide in a few days! Thanks to all! Cheers, Aitor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38224#38224 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Y up to Z up
On 04/01/2011 08:36 AM, Aitor Ardanza wrote: snip Sorry but I need to disconnect with this issue until Monday... I haven't gotten the animations work well, even putting Y up or with the formula R' = M * R * Minv... On Monday I will try to summarize all my tests with pictures and videos ... I can sympathize :-) It took me a week to get a tracking system with a Z-down/X forward coordinate system to play well with my Z-up/Y-forward apps. Getting different coordinate systems to play well together is probably one of the hardest things to get right. Fortunately, you just have to get it right once, then you can put the code inside a black box and never look at it again :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Y up to Z up
On 03/31/2011 09:35 AM, Paul Martz wrote: Rotate 90 degrees around the x axis (or -90, depends on right- versus left-handed coordinates; try one, then the other, to see which one works). This is not a secret. :-) There is plenty of OSG code that does this. Most of the OSG plugins support an option to transform from a y-up to z-up convention. -Paul Also, if you're trying to rotate an orientation (not just a point), you may need to use this form instead: R' = M * R * Minv Where M is the matrix to rotate from Z-up to Y-up, Minv is the inverse of M, and R is the rotation in the foreign coordinate system. Essentially, the idea is to rotate to the Kinect's coordinate system, apply the Kinect's rotation, then rotate back to your application's coordinate system. It's a bit counterintuitive, but that's how the math works out. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] new-bee question on mdl and md2 samples
On 03/29/2011 03:52 PM, Jitrapon Tiachunpun wrote: Hi, Thank you for your answers! What I was asking was, could osg load mdl model files into any obj or osg files with all the textures in as part of an object in the world? Yes, definitely. In fact the .bsp loader relies on this in order to load .mdl props into Half-Life 2 maps. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compiling iOS / iPhone - build errors
On 03/29/2011 04:14 PM, Ryan Atkins wrote: I'm trying to build the latest source from Git for the iPhone https://github.com/openscenegraph/osg.git 'GL_COMPILE' was not declared in scope 'glNewList' was not declared in this scope 'glEndList' was not declared in this scope 'glCallList' was not declared in this scope Those functions are for display lists, which aren't available in OpenGL ES. I've followed the instructions in README.txt, but I get thousands of the above errors. I also have added the frameworks: QuartzCore, Foundation, OpenGLES, UIKit, CoreGraphics as they were added from my ccmake. In my ccmake configuration there wasn't an option to disable OSG_GLU_AVAILABLE as per the instructions. Also, I downloaded OpenFrameworks Git to get the FREETYPE libraries and set them up like this (with absolute paths, but i've truncated here): FREETYPE_INCLUDE_DIR_freetype2: openFrameworks/libs/freetype/include/freetype2 FREETYPE_INCLUDE_DIR: openFrameworks/libs/freetype/include/freetype2 FREETYPE_LIBRARY: openFrameworks/libs/freetype/lib/iphone/freetype-iphone.a I'm not the OSG iPhone expert, but I don't think those settings are your problem. It sounds like you've got CMake set up to compile for regular OpenGL and not OpenGL ES. I believe you need to turn off OSG_GL1_AVAILABLE, OSG_GL2_AVAILABLE, and OSG_GL3_AVAILABLE, and turn on OSG_GLES1_AVAILABLE and/or OSG_GLES2_AVAILABLE (depending on which model iPhone you're targeting). If you've got these settings correct, then something else is going on, and you'll have to wait for more qualified help :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Interest in new releases of 2.8.x?
On 03/26/2011 04:39 PM, Jean-Sébastien Guay wrote: We're using 2.8.3, but we have no real problem waiting for an eventual 3.0 or whatever comes. Off the top of my head, there are no fixes that we absolutely need. That's why I didn't respond to your questions about 2.8.3.1 or 2.8.4... And I guess others are probably in the same position, given the underwhelming response in this thread. I'm in the same boat as J-S. We're fairly happy with 2.8.3 at this point. We wouldn't mind a 2.8.4 release, but we don't have any immediate need for an upgrade. We do have some work going on with some of the new mobile stuff (iPhone/Android), but those guys are fine with using the trunk for that work, and it seems that many of those features aren't quite ready for a stable release anyway. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.4 RC2 tagged
On 3/28/2011 6:38 PM, Chris 'Xenon' Hanson wrote: Please, everyone who cares about this, grab and build this so we can have confidence it's done properly and solid and can call it complete. Builds fine on RHEL 6, including the dae and ffmpeg plugins. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt file not working
On 03/25/2011 03:00 PM, Gordon Tomlinson wrote: I would expect Creator to handle things better than OSG as Creator has a quite a robust and forgiving FLT file reader ( as it should : ) ) , and it can handle malformed files quite well, it will skip records it does not know etc. and try to create usable structure, you might see issues in things like the material and color pallets etc. Yeah, I know. I've found the OSG loader to be at least somewhat forgiving, too. I guess I'd just expect it to get something on the screen, even if it's not completely correct. If you save the file out from Creator then it will be upgraded to the version of open flight and written out with the correct records etc. You lose details that were to malformed for Creator to handle etc.. Also you might look in the Creator log it may have spit out some warnings or notices about the original file I did check the error log. Didn't see anything relevant. Also what version of Open Flight was the original file written by Terra Vista ,as this may affect the ability of the OSG to read the file, Creator will read files in back as far as V12 and maybe even earlier depending on the file, but some things are no longer supported by Creator so you can get some oddities on versions earlier the V14 Peter's file was 15.8. The one I sent will be 16.4. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] new-bee question on mdl and md2 samples
On 03/22/2011 10:53 PM, Jitrapon Tiachunpun wrote: Hi again, Thank you for your reply! I've tried to set the path to what you have suggested me. In my case, I set it to point at the hl2 root as you said.. well, apparently some models are successfully loaded with all textures correctly applied onto them. However, some still lack all the textures. I extracted every single files from the gcf file and leave them as they are arranged in the gcf (e.g. some models are located in models/Effects/models... etc. I'm pretty sure that their corresponding textures are also extracted, since I double-checked the texture names and such and they are located in materials folder exactly as they are in gcf file. Still, it doesn't find the textures.. I guess maybe the textures are located in another gcf files with the same name ? I don't know. That's possible. The Source engine uses a virtual filesystem scheme that essentially merges all of the .gcf files involved into a single filesystem. You might want to look through the other .gcf files you have to see if the missing materials/textures are there. I have a few more questions to bug you though =P : I guess this is a stupid question but, is it possible that an osg environment file able to load mdl models into them with all textures ? I'm having trouble parsing that question :-) Can you rephrase? And, is the plugin able to import simple animation information in the mdl file as well? Let's say I have a model that simply rotates forever (like a ball). (I have not tried this because I couldn't load this model in the osgviewer.) No, I wasn't able to get skinning or animations working in the time I had. All the data is there, and OSG should be capable of rendering it. It would just take some more work to dig the necessary information out of the files and convert it to the required OSG objects. It's fairly hard to do, though, because the file formats aren't really documented well. To get the information you need, you pretty much have to dig through the source code of the Source SDK and try to figure out how the various structures and data fit together. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL for non-rendering operation
On 3/23/2011 3:37 PM, Simon Kolciter wrote: Ok, no access to the whole geometry in geometry shader. However, since you can access to gl_Position of every vertex for a given primitive, can't you also access gl_Normal of these vertices? Accessing gl_Normal only makes sense if you've provided the normals to GL/OSG along with the vertex positions. I thought you didn't have the normals (which is why you needed to calculate them in the first place). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL for non-rendering operation
On 03/22/2011 12:31 PM, Chris 'Xenon' Hanson wrote: You should be able to do what you're looking for on-GPU. There are some cache and read/write issues when you need to write to a data store and then immediately read it back and use it for drawing. Others can comment on that. I haven't done this myself, but from what I've read/heard, the way to do this would be to submit the vertices to a geometry shader, compute the normals in the geometry shader, then use transform feedback to stream the new normals to another vertex buffer which can then be used for rendering. If you want smooth shading, you may need to use one of the primitives that includes adjacent vertex data. Look at the specs for ARB_geometry_shader4 and EXT_transform_feedback for more info. I don't know how well OSG supports transform feedback at this point, either, so you might have your work cut out for you if you go this direction. In any case, there shouldn't be any need for a trip back to the CPU, unless you need the normals for some task other than rendering. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Culling and intersects with ocean and model...
On 03/22/2011 04:44 PM, tim paige wrote: And... I'm sure you or others might suggest the ultimate shading tutorial... This one seems good. I haven't read the whole thing, but I've used sections of it in the past... http://www.lighthouse3d.com/opengl/glsl/ That, together with the osgshaders example should help get you up to speed on using shaders in OSG. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] new-bee question on mdl and md2 samples
On 03/19/2011 10:38 PM, Jitrapon Tiachunpun wrote: Hi Jason Daly, I have a similar question to pradeep. I know that you wrote the mdl plug-in for Valve's model to be read in osg. However, after I've done extracting all the model files and texture (vtf) files as exactly as how the original files are organized in the gcf file, when I tried to view the model using osgviewer, it still says that it couldn't find a particular texture file. How exactly do I need to organize the file? Currently I have the following: hl - models (mdl files are here) materials (vtf files are here) maps After trying to view mdl file, it couldn't find the texture files in materials folder. The simplest way is to point OSG at the root of the hl2 stuff. The loaders know to look in models, materials, or maps for the appropriate content. If you're on Linux (bash) try this: export OSG_FILE_PATH=path to the hl directory osgviewer models/model to load or, on Windows, from a command prompt: set OSG_FILE_PATH=path to the hl directory osgviewer models\model to load Hope this helps... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image as the viewer's background on Iphone
On 02/25/2011 05:22 AM, Stephan Maximilian Huber wrote: 2) your width and height doesn't make sense to me. the native resolution of an iphone 4 is 480x640 or 960x1280. Use osg::GraphicsContext::getWindowingSystemInterface()-getScreenResolution(0,w,h) instead. Umm, the iPhone 4's resolution is 640x960, isn't it? Am I missing something? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osg.js
On 02/23/2011 11:35 AM, Cedric Pinson wrote: Hi, Try those link to enable webgl. http://www.khronos.org/webgl/wiki/Getting_a_WebGL_Implementation Note that on chromium webgl is enable by default Cedric On Wed, 2011-02-23 at 17:06 +0100, Neil Neilson wrote: Hi Cedric Very interesting project. I have Firefox 4.0 Beta 11 and tried several of the Demo apps but just get this error: Could not initialise WebGL Does something need to be set in the browser? I thought that the latest versions of Firefox 4 beta enabled WebGL by default, too. I just downloaded it last weekend, and the WebGL demos all worked fine out of the box. If I remember, I'll give this a try tonight and report what I find. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] OSGbin 2.9.9 v. 2.9.11
On 02/23/2011 07:29 PM, Neil Neilson wrote: Trying the examples in ..\share\OpenSceneGraph\bin None of them work now but did with the pre-built 2.9.9 that does not have the osg71-. osg.dll was not found OpenThreads.dll was not found The fact that the examples don't work, but osgviewer.exe does makes it sound like you're mixing pre-built examples with the OSG libraries you built. By default, the examples are not built when you create a new project from CMake. I'm not sure where you got these pre-built binaries from, but the so version (the osg71- thing) has been used in OSG for a long time now, and as many others have said, it's not something you should be trying to get rid of. I found these osg71- things were just an intermediate on their way to their final resting place (as almost described in Robert's note). One MUST run the INSTALL build after building to ensure the intermediates are moved and renamed to their proper destinations. The osg71- things are NOT intermediate files. The final .dll's in bin/ should have the so version prepended. The plugins (the ones that start with osgdb_) will not have the so version prepended, but they should be in a subdirectory osgPlugins-2.9.11. I personally would advise you to completely eliminate the pre-built OSG that you were using and start from scratch with a fresh OSG source tree. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
On 02/03/2011 04:53 AM, Jorge Izquierdo Ciges wrote: I've been working with ndk r-5 and compiles without many changes. The main trouble i've seen so far it's that following ndk-build script, the library osg goes up to 36 mb (libosg.a). The worst thing it's that it seems that you cannot use a flag to strip unneded coded. Right now i'm playing a little with flags compiler to try to minimize the size, when Rafa and me compiled with the toolchain the filesize of libosg.a was about 9mb (big, but acceptable) latter i'll upload the files that i'm using right now. They can be used either with ndk r4 crystax or ndk r5 Jorge, have you managed to make any progress on this? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image brightness using osg::DrawPixels and polygon texture rendering
On 02/16/2011 10:44 AM, Eric Sokolowsky wrote: Hello, Does anyone have suggestions on getting the textured version brighter, hopefully as bright as the DrawPixels version? The textured version is probably getting dimmer because of the linear magnification filter. Since your background is black, any pixels in the image that are partially covering a pixel on the screen are getting mixed with the black background and the overall luminance is lessened because of that. The DrawPixels version is obviously blocky because you're drawing without any kind of magnification filter. If you switched the mag filter settings on the texture version to GL_NEAREST instead of GL_LINEAR, I imagine your results will look very much like the DrawPixels version. Of course, the real problems is that you're rendering the given image to a resolution that is significantly larger than its actual size. Ideally, you'd want to enlarge the original image to as close to the target resolution as you can before using the texturing operations to draw it to the screen. I don't know the source of the image, so I don't know if it's possible or practical to do this, but that would be the best solution. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Has anyone write osg::AudioSink for openal?
On 01/28/2011 11:53 PM, Lilinx wrote: hi,all same as tile!! Not yet, to my knowledge. I was going to tackle it at one point on my own, but it turned out to be a bigger job than I first thought. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
On 01/28/2011 10:01 AM, Jean-Sébastien Guay wrote: Yeah, really nice. Anyone try to compile OSG with this NDK? I guess since they say it supports RTTI and has STLPort for the STL, it should work fine... Actually, there are four different C++ libraries available in NDK 5, and the only one that supports exceptions and RTTI is a static build of GNU libstdc++. There are both static and dynamic STLPort builds but neither supports RTTI or exceptions. They're working on a dynamic version of GNU libstdc++ for a future release. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mixing GLSL shaders and ARBv1.0 shaders
On 01/27/2011 12:58 PM, Steven Powers wrote: I'm working with some legacy code that uses ARBv1.0 shader code for some of the leaf nodes. The ARB shaders work just fine but they are never envoked when I place a GLSL shader (simple shadowing shader) on the root node. I've tried setting the mask of the ARB shader to ON | OVERRIDE | PROTECTED and I made sure the mask of the GLSL shader is ON | OVERRIDE. If I swap the ARB shader on the leaf node with a stand-in GLSL shader it works fine. Some differences: ARB shaders are loaded as osg::VertexProgram and osg::FragmentProgram GLSL shaders are loaded as osg::Program with osg::Shader attached. Both implementations share the same Node with identical state sets. Any clues are appreciated. ARB and GLSL are two different StateAttributes. OSG will treat them as orthogonal, but the hardware obviously won't. Or, to put it another way, you can't have both GLSL and ARB programs running, but OSG probably doesn't know that. You probably need to explicitly turn off the osg::Program at the same time as you enable the osg::VertexProgram on the nodes in question. Something like this: stateSet = node-getOrCreateStateSet(); osg::Program * program = new osg::Program(); stateSet-setAttributeAndModes(program, osg::StateAttribute::OFF | osg::StateAttribute::PROTECTED); --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
