Re: [osg-users] VR2008 attendees?
Bob Huebert wrote: Greetings, Are there any osg folks going to be attending the vr2008 conference next month? If so, would it be possible to get together and put some faces to names? We've got a small crew going from my lab. I wouldn't mind meeting up, but I probably should coordinate with my group. Did you have any ideas about when yet? -- --J I'm a castaway stranded in a desolate land, I can see the footprints in the virtual sand. --Neil Peart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vector class Hacks?
Mike Weiblen wrote: std::vector is guaranteed to have contiguous memory. So vector.front() or (vector[0]) are legal references to the first element of a c-style array. That is why it is important to preallocate vectors to the expected length when possible, to avoid the reallocation hit necessary to preserve contiguous memory. std::deque has similar accessors, but is not contiguous, so reallocation is much cheaper, but you cant use as a c-array. It's not a hack, it's documented and legal behavior. This behavior is not mandated by the standard, but there is a resolution proposing it be made so (for all types other than bool): http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-defects.html#69 --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-conv collada
skunkwerk wrote: could someone please tell me how to create the collada db so osgconv can load collada files? i can't find any documentation on this. If you installed the COLLADA DOM, you should just need to make sure CMake can find it (run ccmake . again and specify the path, if necessary) and then re-make OSG. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-conv collada
skunkwerk wrote: thanks Jason, here's the output - it seems that it eventually finds the plugin, but dlopen complains about an undefined symbol in the osgdb_dae.so file - how can I fix this? I don't know. This might require the assistance of the CMake folks. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: FLT export
Paul Martz wrote: Hi All -- I recently posted a change to osg-submissions that adds FLT export capability to OSG. Assuming it doesn't break the build, I expect Robert will have this available on current SVN soon. Hi, Paul, Great work! I tested with a fairly complex .ive. Originally this was an OpenFlight database. During export, I got a lot of these errors: fltexp: GL_POINTS not supported in FLT export. I'm not worried about actually exporting the points, as they weren't important anyway. I'm just mentioning them in case it's relevant for the real problem. This happened when I went to view the exported .flt file in osgviewer. During load, I got several groups of these two warnings: Warning: data error detected in VertexCNT::readRecord uv=nan nan Warning: data error detected in LocalVertexPool::readRecord uv=nan nan The file does eventually finish loading, and it looks fine for the most part. However, there are several objects in the scene that are missing large groups of faces. In each case, the bulk of the object is there, but there are large holes in it. Many of these objects used to be external references that were duplicated multiple times, and each copy looks the same. I really wish I could send you the file, but alas, I cannot. I'm sure this isn't enough information for you to go on. Let me know what else I can do to help. -- --J I'm a castaway stranded in a desolate land, I can see the footprints in the virtual sand. --Neil Peart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Highly detailed closed scene navigations...
Robert Osfield wrote: Hi Neil, PagedLOD is what you need to use to balance the load for really large databases. You databases are likely to huge though, gigabytes rather than terrabytes, and the OSG' paging system allows you to scale to terrabyte database pretty comfortably so you'll do just fine is you manage the scene structure well. Doing it well is not a trivial task though so expect to be effort in learning about the issues and time experimenting with different scene graph structures. You might also want to use some high level cull callbacks that cull subgraphs based on which room floor you are as this way you can get more effective culling. You can enclose each region with its own bounding mesh - see osgSim::VisibilityGroup for this type of culling. One thing you want to be careful about is tricks like relaxing such culling to allow the pager to start bringing in the new floor level prior to it becoming visible. Hi, Neil, Not sure if this is appropriate for your case or not, but when I had to model an office with several rows of cubicles, and then run it on a wearable computer, I found the osg::OccluderNode to be a great way to bring the frame rate up. The cubicle walls made obvious, natural occluders for all of the complex furniture models inside them, so I only ever had to draw the few pieces of furniture that were potentially visible. In your case, you've also got actual floor-to-ceiling walls that would make even better occluders. One potential problem is that I'm not sure how well they scale. My environment was just a section of a building that had an open plan, while yours seems a bit larger. There's a tradeoff between the number of occluders in the scene and the potential performance gains, so you can't have too many occluders active at once. However, if you combine this with the PagedLOD's and a higher-level culling scheme, you might come up with something that both fits in memory and runs pretty quickly. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Highly detailed closed scene navigations...
Robert Osfield wrote: Hi Neil, When you start to deal with really large datasets that paging and culling are tools that you'll need to use effectively, you'll need to understand load balancing of the system. Primarily what you'll be doing is building an appropriate database rather than optimizing at the code level, to do this you'll need to understand the code and the hardware of course. Don't expect to find a silver bullet for this work, items like using occlusion culling is just another tool in your toolbox, instead you need to gather lots of tools in the toolbox, understand them and how to build a database that uses them efficiently. Hi Neil, I second this. With the scene you're discussing, I wouldn't expect to be able to sprinkle a few OccluderNodes around the scene and have it magically work and run at 60fps. If your database already won't fit in memory, you're at least going to need to do some paging. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cyclic graphs?!
Art Tevs wrote: Hi folks, as far as I can see for now osg doesn't check if the given scene graph contains cycles. If one do this, then there is a seg fault, if my test were correct ;-) However imagine I have a situation, where I need to have a cycle in the graph. For example: ... Any ideas about that? Scene graphs are typically Directed Acyclic Graphs by design. If you introduce a cycle in the scene graph, most folks would say you're using it wrong. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cyclic graphs?!
Art Tevs wrote: However let us think on something like extended scene graphs where cycles are also more or less possible ;-) Does anybody already made some thoughts on that? Hi, Art, I'm sure it's been pondered in the past, I'm just not sure it's relevant to OSG's purposes. Maybe you've got a cool idea that requires that kind of structure, but it seems like a really fundamental change that could introduce all kinds of problems. Unless there's a really compelling reason for it, I wouldn't want the added complexity. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setResizeNonPowerOfTwoHint supresses messages only?
Hi, Mike, Mike Greene wrote: While this did stop the messages from coming to the screen about the texture being resized, it did NOT seem to speed things up. I have two sets of texture sequences - one that is 800 x 600 and one that is 1024 x 512. The latter probably runs 10 times faster, even though there is more pixel information in the file. Does your hardware support the ARB_texture_non_power_of_two extension? If not, the textures will get resized anyway. You can also try using osg::TextureRectangle instead. The only issue here is that you'll have to switch to non-normalized texture coordinates for your geometry. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada Animation
Kim C Bale wrote: I’ve been using the Feeling Software ColladaMax exporter for 3DSMax to export models so that I may use them in OSG. Now plain models work a treat. However, I have been given a file that contains an animation, and the animations don’t appear to show when I load them into osgViewer. I had a feeling that they wouldn’t, but is there something that I can do to enable them? Does anybody have any experience getting Collada model animations into osg? Is it supported at all? Not by OSG. The problem with COLLADA animations (which is actually a good thing in most respects), is that you can really animate *anything* in COLLADA (from transforms to material/shader parameters), so it's quite a bit of work to get animation working in a complete way. The other constructs not supported by the OSG loader are controllers, such as skins and morph targets. If your file contains these, you won't see them either. Most of the time geometry is attached to one or more skin controllers. The bones of the skin controller are then transformed, and the transforms are animated. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load all 6 images from cubemap dds.
Robert Osfield wrote: Hi Joakim and Roland, On Mon, May 5, 2008 at 6:46 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Joakim, I sent in a submission last year for loading complete cubemaps from DDS files. That submission affects important parts of the osg core and therefore Robert put it on the stack, which in practice means that it won't be merged soon. This is a good reminder. Now we have stable release out of the way its not a bad time to start considering changes that might require more widespread changes. Roland could you have have a go at migrating your changes to 2.4/SVN and then resubmit. On a different, but related note, does anyone have an idea how one would go about reworking the isImageTranslucent() method of osg::Image to handle S3TC images (like you find in .dds files)? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building the SVG plugin
Philip Lowman wrote: Can GTK and rsvg/cairo be built under Visual Studio? They can (I've done it), but it takes a bit of work. The Visual Studio modes of compiling aren't well-maintained by some of the libraries. The trickiest one was fontconfig (a dependency of rsvg). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake issue on RHEL 5
Hi, all, On Red Hat Enterprise 5 (update 2), I'm getting the following from CMake with the latest svn: CMake Error: PkgConfig_DIR is not set. It must be set to the directory containing PkgConfigConfig.cmake in order to use PkgConfig. This is with CMake 2.4.5 (the version that ships with RHEL 5). I checked out the 2.4.0 tag, and that one builds fine, so I'm guessing this came from the recent additions for the SVG plugin. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How can I archieve antialiasing in osg 2.4?
Leeten wrote: Hi, all I'm using OSG 2.4 and I can't find GL_LINE_SMOOTH or GL_POLYGON_SMOOTH something in it. The lines and edges of polygons in my scene are jagged(shownin the attachment), so I'm trying to find some antialiasing way. I've tried the fllowed way which seemed helped nothing. 1) set theMode of scene group with GL_MULTISAMPLE_ARB; 2) using osg:: DisplaySetting-insence()-setSampleNum(4 or 8 or 16); 3) set the Attribute of scece root with osg::Hint or osg::MultiSample; all above occured nothing change of the jagged edges and lines. Could someone hits me a little? Your hardware has to support multisample anti-aliasing for the above code to work. What hardware are you running? (If we know what you have, we might be able to give you more specific help). Try looking in the display properties. If you've got Nvidia hardware, look in the Manage 3D Settings panel of Nvidia Control Panel and try changing the Antialiasing - Setting property. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Robert Osfield wrote: The new code is in OpenSceneGraph/CMakeLists.txt is: #use pkg-config to find various modues FIND_PACKAGE(PkgConfig) IF(PKG_CONFIG_FOUND) ... Yes, as I said, that code is in the version I have. This should prevent problems. Could you please post problems you get once you try 2.5.1 or the SVN version out. We can't fix problems if we don't specifically know what they are. Sure, I'll try it again once it's released. I'm mainly posting now because you asked us to test current svn :-) I've tried to give as specific information as I could. If there's anything else I can do to help track down the problem, I'd be happy to provide it. As for the statement Red Hat Enterprise 5 won't be able to generate Makefiles, I think this is rather overblown. First up there is nothing stopping you downloading and installing a more up to date version of CMake. I could easily do that on one workstation, yes. It's more of an issue when you're dealing with a lab of several dozen workstations. This is why we pay to run Red Hat Enterprise. You can even not bother installing it and just set your PATH/LD_LIBRARY_PATH to pick up on a local install. pkg-config is in my path, what else do I need to do? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Robert Osfield wrote:
Hi Jason,
I have introduced the follow:
IF (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
FIND_PACKAGE(PkgConfig)
ENDIF(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
Hopefully this will fix your outdated CMake build problems.
Thanks, I'll try it soon. I'm putting out a fire (figuratively) 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] CMake issue on RHEL 5
Robert Osfield wrote: I could easily do that on one workstation, yes. It's more of an issue when you're dealing with a lab of several dozen workstations. This is why we pay to run Red Hat Enterprise. Pay for out of date tools... do you get upgrades included? Of course, in fact, we get upgrades that are fully tested and guaranteed to be compatible with the rest of the system. As a result, you don't always get the very latest version of software, but you get a very stable system. I doubt Red Hat will deploy CMake 2.6 until RHEL 6. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Robert Osfield wrote:
Hi Jason,
I have introduced the follow:
IF (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
FIND_PACKAGE(PkgConfig)
ENDIF(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
Hopefully this will fix your outdated CMake build problems.
Hi, Robert,
That does indeed make the elder CMake happy again.
Thanks!
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Robert Osfield wrote: On Sat, May 31, 2008 at 7:20 AM, Philip Lowman [EMAIL PROTECTED] wrote: The posted workaround of checking the version number will work fine, alternatively one could replace FIND_PACKAGE(PkgConfig) with INCLUDE(FindPkgConfig OPTIONAL) Which eliminates the error message (and I have verified this on CMake 2.4.6 =) ) Ahh this is much cleaner than my version hack. Now checked into SVN. Works for me. --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 find plugin
Peter Wraae Marino wrote: Hi, I just got into this thread now.. I too am having problems with the .ttf format. As I can understand.. the fix is too make sure to have service pack 1 installed for developer studio. This is only true if you're running Visual Studio 2005 I'm using express 2008 and there doesn't seem to be any service pack for it, it actually seems like the 2008 version has indirectly installed service pack 1 when the application got it installed. I don't think Mike has created a 2008 version of the 3rdPary binaries yet, so if you want to use them, you may have to grab the sources and compile them yourself. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Camera::FRAME_BUFFER_OBJECT, on-screen windows not reflecting rendered image
Goldman, Jon wrote: (note: for some reason my email reader did not receive your latest message from this thread, and therfore to quote I had to paste from http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-June/012825.html) Robert, to answer your questions-- -- Yes, all the windows are on screen at the same time; -- They are rendering the same scene graph, but each window has a different camera view into the scene; -- Due to the architecture of the overall larger application that our OSG codes are linked with, we can not use one onscreen window. I did test our OSG-based codes with osg::Camera::FRAME_BUFFER_OBJECT, on another Windows XP box that has a NVIDIA Quadro FX 3000, and saw the same results. Unfortunately our application is also running C#, and a Windows COM server at the same time, so we can not test on Linux or UNIX. This is just a thought, but since you're using a Quadro, what happens if you disable the unified backbuffer in the NVIDIA control panel? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.5.3dev release
Robert Osfield wrote: Hi All, I have just made some changes to the includes of the new OpenThreads/Config and osg/Config headers that address a cmake build error that was occurring on out of source builds. Fingers crossed this will be now fixed, and no other platforms will be broken, but as ever, it needs testing to be sure that things are working fine. Out of source (OpenSceneGraph/build) on Red Hat Enterprise 5 builds and works fine. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OT: Collada with Embedded Textures
Steven Thomas wrote: To add salt to the wound the Collada DOM (which OSG uses for Collada parsing) doesn't support the data element. Tellingly, no one's ever complained about that. That's rather amusing :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linux Dev. Env. Poll
Can T. Oguz wrote: Dear OSG Users, May I Ask which linux distribution and development environment you chose to work on ? Red Hat Enterprise 5 Linux at work Fedora 9 at home. I use Windows when I'm forced to, but I still do the development on Linux. Vi for editing (including on Windows), SCons for building. Xxdiff is a great graphical diff tool. Winmerge is the closest thing I've found on Windows. I agree with Robert on the raw productivity that the good old fashioned command line can give you. Most of the time IDE's just get in my way. I used to use Visual Studio when I had to build stuff on Windows, but now SCons lets me avoid that. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAudio / openAL
Sukender wrote: Many thanks! I always wonder what OpenAL-Soft was, but I never took a look at it... I'm going to recompile all my dependencies using it (if possible). So I think the OSG audio would depend on it rather than on the original OpenAL, don't you think? Yes. The OpenAL-Sample directory is effectively deprecated. OpenAL-Soft is providing the cross-platform sample implementation now. The only hang-up with OSG might be that there isn't a backend for some of the platforms that OSG supports (IRIX, for one). Also, OSX might need to rely on the implementation provided by Apple (I'm not sure if OpenAL-Soft supports it). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build problems with undefined _gl references inCygwin
Brian Keener wrote:
Typing esc only destroys the window without stopping the program, which
continue with a
dangling viewer pointer; no wonder that you have to kill it manually.
Instead of calling glutDestroyWindow(glutGetWindow()); it should call
exit(0); , maybe after
calling delete viewer; .
I think he's right about the exit() call. The delete viewer should
already be taken care of by the ref_ptr.
void display(void)
{
// update and render the scene graph
if (viewer.valid()) viewer-frame();
// Swap Buffers
glutSwapBuffers();
glutPostRedisplay();
}
glutPostRedisplay(); will have display() called again, so it creates an
infinite loop.
It should not be there. glutPostRedisplay(); should rather be at the end
of
mousebutton, mousemove, and keyboard.
Seems to me that the viewer-frame() call should be in a glutIdleFunc,
not a glutDisplayFunc(). From the man page:
The amount of computation and rendering done in an idle callback should
be minimized to avoid affecting the program's interactive response. In
general, not more than a single frame of rendering should be done in an
idle callback.
So, it's acceptable to render a single frame from the idle callback.
The display callback is better used for programs that don't need drawing
to be done continuously. OSG apps don't typically fall into this category.
Closing the window with the (X) icon should result in simply calling
exit(0) and destroying the
window. As to why it segfaults, you would have to degug it, as I don't
have
OpenSceneGraph installed.
Probably the viewer isn't being cleaned up in this case, and it still
tries to draw with an invalid window or context. This is just a guess,
though.
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Roger James wrote: So Collada is giving us emission, ambient, diffuse, and specular elements which can be either a fixed colour or a variable colour acquired from a texture map. In the OpenGL pipeline the lighting calculations are done prior to the fragment shading. The only exception is the specular highlighting which we can optionally postponed until after the fragment shading phase. So I would suggest that the starting position is that any textures in the emission, ambient, and specular elements are ignored. If a texture exists in the diffuse element then a default value (probably white) can be applied as the fixed diffuse colour and the texture used to modulate (GL_MODULATE) the incoming fragment colour in the fixed function fragment shader. The common profile does not allow multiple techniques to used in an effect, i.e. no multitexturing. I've seen light maps and ambient occlusion maps placed as a texture in the ambient channel along with a regular diffuse texture in the diffuse channel. I've implemented this in my own code with simple fixed-function multitexturing before. Is there a reason not to do this? If the diffuse channel contains a texture and the shininess element is non zero then specular highlighting should be postponed. I cannot think of a way of handling the index_of_refraction. Has anyone got any thoughts on this? That would have to be done with a shader implementing Snell's Law (I'd copy it here, but I don't know how to type a theta character. Just look it up on wikipedia if you're interested :-) ) Reflective and reflectivity need further study. Anyone got any ideas? I think these are intended for environment maps. Reflective holds the map itself (or just an overall color), and reflectivity specifies the blending factor between the surface and the environment. That leaves the thorny issues surrounding the transparent and transparency elements. This is what the Collada spec has to say about then in general terms. It sounds like you've done more research than me here, so I don't think I can contribute much more :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Roger James wrote: I was assuming that because the lighting equation (blinn) has already been applied in the pipeline before textures are applied, that if we wanted to use a texture map to supply the ambient terms to that equation, then the lighting equation would have to be somehow re-implemented in a fragment shader. I did not think the the fixed functionality could be configured to handle it, especially the contributions from light sources. I am happy to be wrong in this. Well, thinking about it more, in order to get it mathematically correct, you're probably right. However, fixed-function multitexturing can give a reasonable facsimile (especially with an ambient occlusion map in the ambient channel). The right way to implement all of this is probably to write a COLLADA Blinn shader (as well as one for Phong, one for Lambert, etc.) and avoid fixed function altogether. Unfortunately, this leads to problems if users want to make use of their own shaders. The transparency bit is the bit that needs fixing. We are just not handling transparent textures at the moment. I would really appreciate your input in this area, as I feel that I am just wandering about in the wilderness on it at the moment. I don't really remember enough about how this works. I know there are issues and subtle differences regarding A_ONE and RGB_ZERO modes, and I thought I even heard the spec for this changed between 1.4 and 1.5 (I wrote my code for 1.4). I'll tell you what I did in my code, but I don't have time to research this further right now. In my code, (which is probably technically wrong, but seems to work most of the time) I check the opaque setting on the transparent color. If it's A_ONE, I use the transparency value as the alpha on the material (the OpenGL material, that is). If it's RGB_ZERO, and transparency is specified as a color, I average the transparency color's RGB values and set the material's alpha to 1 minus the average (this is probably a best-effort kind of hack). If transparency is a texture (an alpha map), I ignore it, since it's not possible to support in fixed-function (at least I don't think it is). Of course, none of this has anything to do with whether or not the diffuse texture has alpha. If the diffuse texture has an alpha channel, this needs to be honored as well. I check for this with a call to osg::Image::isImageTranslucent() on the image from the texture in question. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Jason Daly wrote: If it's RGB_ZERO, and transparency is specified as a color, I average the transparency color's RGB values and set the material's alpha to 1 minus the average (this is probably a best-effort kind of hack). If transparency is a texture (an alpha map), I ignore it, since it's not possible to support in fixed-function (at least I don't think it is). Sorry, that should be transparent instead of transparency above. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Roger James wrote:
if (transparent or transparency element present in the technique)
{
// Turn on the OpenGL blender
Calculate a blending factor using transparent and transparency
according to the opaque mode in force.
// Decide whether to use GL_SRC_XXX or GL_CONSTANT _XXX in the
OpenGL blender
if (the calculated factor would mean opacity when applied)
Use the relevant blend factor from the incoming lit and
textured fragment
else
Use the previously calculated blending factor as a constant
blend factor
}
I would appreciate any comments you have, time permitting of course.
The only thing that worries me about this is that you're using the
transparent/transparency tags to decide when to enable blending.
I'd suggest you add one more check to see if your calculated blending
factor results in the surface being fully opaque before you enable
blending. I say this because I've made a lot of use of the ColladaMAX
plugin from Feeling Software, and every single model I've exported with
that plugin has transparent/transparency set on all of its materials,
even if they're actually fully opaque.
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Smeenk, R.J.M. (Roland) wrote: Hello Roger, I did not make a study of the Collada transparency intricacies like you did. The assumption I made was that a texture for diffuse specifies the diffuse components to use in the texture. The fact that texture coincidently was packed with an alpha channel (which of course happens a lot) should not influence that. When you consider the chain texturesamplersurfaceimage the responsibilities are clearly dividided. It could be possible that somebody decides to pack an ambient occlusion or specular value in the alpha channel of an image. The semantics of the data source should be specified by the texture elements in ambient, diffuse, specular, etc. That's why I added code to only enable blending if a texture was specified in the transparant element. What you say makes sense, but I've never seen it done this way in any of the files I've used or created via COLLADA plugins. I think we need to support the RGBA texture in diffuse channel only model, just because so many files and tools work that way. This isn't ideal, but it's probably necessary. I've been very suprised to see suggested everywhere that the common profile maps to the fixed function pipeline, but this easily falls short if you need to support both blinn and phong. Well OpenGL FFP does not even support phong shading. Gouraud is the closest we get with per vertex lighting. It clearly doesn't map to FFP, but it's as close as COLLADA comes. The biggest problem with handling profile_COMMON with shaders is that it makes it hard for an OSG developer to use his/her own shaders higher up in the scene graph. I think this is what drives the desire to handle profile_COMMON with FFP. I don't know how to map textures specified for both ambient, diffuse, specular etc. to the Ogl FFP. Texture combiners might bring us a little closer, but I hardly consider this the FFP. Well, I believe ARB_texture_env_combine was made a core feature in OpenGL 1.3, so many would consider it FFP. But I digress... Besides what happens if the surface contains a channels specification other that rgb or rgba? It gets even worse if it is allowed to compose 3 channel input for a diffuse texture combining components of three different source images. I am not sure if this is allowed in the profile_COMMON. Though very flexible, who is going to support this? I don't think that is allowed (the schema says only one color or texture per channel). That would get out of hand quickly. I don't think anyone here expects that to work anyway. We're just talking about a single RGBA texture in the diffuse channel. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing the tgz, osgtgz and zip plugins
Ulrich Hertlein wrote: I agree that the implementation is hacky but the functionality is definitively useful (speaking for zip files only): - they are a common way to distribute a complete model (non-OSG objects, textures, etc.) - they can be easily created by the artists, no need to have OSG installed - usable by other packages; .osg, .osga, and .ive are leaf file formats if you will That, and couldn't they be re-implemented using zlib (which is already necessary for the png plugin)? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing the tgz, osgtgz and zip plugins
Gordon Tomlinson wrote: As to re-implementation , who's going to pay my company for the time and expenses to re-rite these go through all r Testing ands sign off procedures ? I don't understand this point. If you get the same functionality, just with a real library implementation and not a hacky system() call, why would you or your company care? Why change something that is not broken, might not be the best solution but they work To me, because it's not the best solution is a good enough reason to change them (to reimplement them in a non-hacky way). I agree that they should not be removed, though. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error with 2.7.8
2.4.5 is also the only binary package (that I know of, at least) that is available for Red Hat Enterprise 5. If you're taking votes, I'd prefer keeping support for 2.4.5. --J Sent from my iPhone On Dec 20, 2008, at 5:38 PM, Mattias Helsing helsin...@gmail.com wrote: Hi Robert, my kids woke each other up so it took an hour to click that send button :-) As I said though we would need to require 2.4.7. I guess for win32 too. I personally would prefer to up the required cmake version because i'm not very fond of the IF(major_version == 2 AND minor_version y) since they will all break when cmake-3.0 arrives. The IF(POLICY CMPxxx) is much better in that respect and easier to read and understand. Also, the fact that this hasn't been reported before proves that not many developers still use cmake pre 2.4.7 On the other hand etch still uses 2.4.5. I don't know if this is important to you. Is it? On Sat, Dec 20, 2008 at 8:59 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Fred and Mattias, I've download cmake 2.4.5 and get the Error: make: *** [cmake_check_build_system] Error 255 And on comment out the block: if(POLICY CMP0008) cmake_policy(SET CMP0008 OLD) endif(POLICY CMP0008) The error goes away and build commence fine. The specific problem in cmake 2.4.5 looks to be how it handles the IF(POLICY CMP0008), if I comment out just this then it also compiles fine: # if(POLICY CMP0008) cmake_policy(SET CMP0008 OLD) # endif(POLICY CMP0008) Attempts at using IF(CMAKE_... version ) to optionally use the above block has failed at my end, just as it did for Fredric. This may well be a bug in Cmake 2.4.5, but given it looks to be an unofficial feature of 2.4.5 perhaps it's not too surprising. What to do about this? How essential is the if(POLICY)? Would it be fine to just go with this commented out? I'm no Cmake expert so can't really answer this, all I know is that block of script came in as part submission and I merged trusting the submission was made be one with a little more cmake knowledge than myself. So again I defer to those more cmake knowledgeable than myself, is it safe to always call cmake_policy(SET CMP8 OLD)? no. I tried this with cmake-2.6.0 and this makes cmake report that you're trying to set a policy that doesn't exist. If it's not then I think we'll just have declare cmake 2.4.5 unsupported, and perhaps add the cmake 2.4.6 requirement to the CMakeLists.txt file? I tried 2.4.5/6/7/8. This won't start to work until 2.4.7. Mattias Robert. ___ 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] CMake error with 2.7.8
Robert Osfield wrote: H Fred et al, I've merged Mattias's changes to support Cmake 2.4.5 2.5.6 with out current build system, this are now checked into svn/trunk. The main CMakeLists.txt is also attached. Could yo'all stuck with CMake 2.4.5 try out these changes. Builds fine on RHEL 5.2. I'm not at work to test it thoroughly, but at least osgversion works :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compile errors and warnings in mdl plugin
Hi, J-S, Thanks for doing the Windows testing I promised to do before I got sick for two days :-) I'd submit fixes for these, but looks like Robert beat me to it. --J Jean-Sébastien Guay wrote: Hi all, Current SVN has errors when compiling the mdl plugin. All the errors are related to the use of the u_char type. Here are the files/lines where it reports errors: ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] finding switch and dof nodes in a 3D model withoutname
Robert Osfield wrote: Hi Francesco, You just need to write a NodeVisitor that traverses through the scene and detects the osg::Switch and osgSim::DOFTransform. The NodeVisitor has an apply(osg::Switch) method, but not a DOFTransform one so you'll need to implement and apply(osg::Transform) and then dynamic_cast this to a DOFTransform to find out whether the transform is a DOFTransform. Just a heads-up... The flt loader uses osgSim::MultiSwitch (instead of osg::Switch) for its switch nodes, so you'll need to write the apply() for that as well. I checked to be sure, and this was the case even in version 1.2. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] is there an automatic method to enable dof?
Francesco Argese wrote: Hi guys, i begin thanking you: I have resolved the problem regarding the research of dof and switch nodes in my flt models: now I have a vector containing all the pointers to switches and dof and i need to activate them. Following the OSG FAQ [1], I have found that a method to enable DOF nodes is to use method setAnimationOn( true ) on my DOFTransform. I have tried this but it give no effect to the scene. I have tried also the function animate() but it doesn't produce any result. What these two functions do? At the moment I'm enabling the dof node towards setCurrentHPR(osg::Vec3(...)) and it works well, but i like to reduce the amount of code if there is another method to do so already integrated in OpenSceneGraph. I'm not sure about this, I've never used those functions. Another thing: what is the function to change osg::MultiSwitch value? I assume you mean osgSim::MultiSwitch. This is a slightly complex question. MultiSwitches, like regular Switches can enable or disable the traversal and rendering of their children. The difference between an osg::Switch and an osgSim::MultiSwitch is that a MultiSwitch can store a list of different ways to configure the switch. For example, you can have one setting that has children 1 and 3 on, and a second one that has children 2, 4, and 5, on. OpenFlight calls these masks (in Creator, you add a mask to the Switch node, and you can then enable or disable children within that mask). OSG calls them switch sets. There is a method setChildValue(), which takes a switch set index, a child index, and a boolean value. This lets you enable or disable a child within a particular switch set. There is also a method called setActiveSwitchSet(), which lets you tell the MultiSwitch which switch set to use. Hope this answers your question instead of confusing you more :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Choice of body-specific coordinate system origin by dae(COLLADA) reader
Fabian Aichele wrote: Hello, osg-users! I have a question regarding the choice of the body-specific coordinate system made by the COLLADA reader (daeReader/Writer in osgDB). When I import a geometry from a COLLADA document, the osgDB plugin returns a osg::Group that contains the nodes declared in the COLLADA document together with all the geometries used by the node declaration, plus material properties etc. That works fine, but there is one thing I haven't figured out yet: How does the COLLADA importer decide where to put the local origin for a node hierarchy imported from COLLADA? I have tested different geometries consisting of 20 to about 50 triangle strips/fans/arrays, but the body-specific coordinate system was chosen quite arbitrarily (at least I couldn't figure out any pattern). This is important for me to know since I use OpenSceneGraph to visualize a rigid body simulation with the Bullet Physics engine, and I haven't managed to get the OSG and Bullet coordinate systems in sync. Any hints or pointers to documentation/examples/earlier questions regarding this are gladly accepted. I don't believe the importer decides anything. All of this information is in the file itself. The root of the document's visual scene is placed at 0, 0, 0, and everything else is relative from there, according to whatever transforms are attached to the visual scene's nodes. If you're seeing an arbitrary origin, it's probably because it was modeled that way (some of the COLLADA test models do have strange origins). The only other influence on the coordinate system comes from the document's up_axis setting in the global asset tag. This describes whether the document's contents are X_UP, Y_UP, or Z_UP. This is used to adjust to the OSG coordinate system (which is Z_UP). 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] Long-standing Particle System File loading IOperformance trouble
David Guthrie wrote: We never create particle systems in code. Artists create them in the delta3d particle system editor. You can see all of your changes and tweaks in realtime and then save an osg file. I don't see creating a particle system as a programming task at all. It's an art asset. I don't see why you would create them in code unless you have no other option. Even then, if you want more than 10 particle systems, you could easily write simple gui utility or just a simple text file to generate them in that amount of time. Delta3D has one that is much better than a simple gui tool. I'll just jump in and say that I've used some particle systems from Delta3D in some of our work (we don't use Delta3D ourselves, but we work with other folks who do). Loading the particle system from a .osg file and cloning it when needed is a pretty convenient way to handle this kind of task. --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 do a cutting plane?
Cory Riddell wrote: I've been evaluating a bunch of software and one product has cutting planes. For these, you define a plane and you can intersect it with your model and it clips the model. Follow this link for a better description: http://www.openhsf.org/docs_hsf/Hoops3DGS/prog_guide/02_13_geometry_cutting_planes.html How difficult would this be to set up with OSG? I'm trying to just get a sense if are all the pieces there or would it be a difficult task? Sounds like you're looking for a ClipNode. Look at the osgclip example to see how it works. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the ideal default value for LIB_POSTFIXunder Linux?
Robert Osfield wrote: It's curious one would create a /usr/local/lib64 and then not provide a library path to it... Can any RedHat/CentOS/Fedora users tell use what /etc/ld.so.conf and /etc/ld.so.conf.d contain w.r.t pulling in /usr/local/lib? No reference to /usr/local/lib on Fedora 6 or RHEL 5. Here's the entire contents of the relevant files from a RHEL 5 box: cat /etc/ld.so.conf include ld.so.conf.d/*.conf ls /etc/ld.so.conf.d/ qt-i386.conf cat /etc/ld.so.conf.d/qt-i386.conf /usr/lib/qt-3.3/lib I've actually installed software into /usr/local/bin on my Fedora 6 box that relied on companion libraries in /usr/local/lib, and had to adjust my LD_LIBRARY_PATH to get them to run. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] First cut at NEWS item for OpenSceneGraph-2.8
Robert Osfield wrote: On Thu, Jan 29, 2009 at 4:10 PM, Paul Martz pma...@skew-matrix.com wrote: Thanks for posting this. You might add support for OpenGL draw instanced functionality. How about, New plugins for loading Half-Life 2 maps and models. I could add a nice screen shot, but I'm not sure what the legal implications of that would be (all of the art would be copyrighted by Valve). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdb_freetype.dll not getting built
Sinisa Kolaric wrote: Hi I am trying to compile OpenSceneGraph 2.6.1 on Windows XP, but it looks like CMake can't find FreeType in this source snapshot; the resulting VC++ 2008 project thus does not contain a reference to this plugin. So when I run a sample application (for example osgautotransform.exe), I get a bunch of Warning: Could not find plugin to read objects from file ...\fonts\arial.ttf, simply because osgdb_freetype.dll isn't there - it wasn't compiled. I downloaded the latest version of FreeType (2.3.8) and added a reference to its include source manually in CMake, but the resulting VC project still doesn't contain a reference to it. Any ideas? Thanks, If you're pointing CMake at it manually, you'll also have to tell it where the library file itself is (not just the includes). --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.0-rc1 tagged, please test
Robert Osfield wrote: But still we can't rest if we want to make 2.8.0 the best we can... so please download/check out the OpenSceneGraph-2.8 branch or the 2.8.0-rc1 and do compile and runtime checks on as wide range of platforms as you have to hand. I would also greatly value feedback on how you own applications are performing with 2.8, if there are issues please just report them on osg-users and we can together have a bash at resolve them. Builds with zero warnings on Red Hat Enterprise 5.3, even with our tired old CMake 2.4.5 ;-) Only minor glitch with the build is that I have to pass -march=i686 in CXXFLAGS for OpenThreads to configure properly to use GCC_BUILTINS. I think this was covered in another thread a few months back. Even if I don't do this, it works fine running with mutexes. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] exporting from OSG to OpenFlight
Paul Martz wrote: When you said node in your original post, I thought you were referring to OSG Nodes, not OpenFlight records. :-) The flt plugin options are documented here: http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/OpenFlight (the wiki seems to be down at the moment, so I was unable to verify this bookmark.) I think you want to have version=15.6 in your Options string. This will export a 15.6 model without the Mesh record. Fyi, the earliest supported version seems to be 15.7, so I'm not sure this method will work. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cull time doubled?
Pecoraro, Alexander N wrote: What version of Linux/GCC/processor that supports the built-in atomic functions? Alex, On RHEL 5, you have to *explicitly* set CXXFLAGS to -march=i486 or higher *before* running CMake. For some reason, the default configuration will evaluate to using mutexes, even if your CPU supports the GCC builtins. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] floor looks dark
Daniel Drubin wrote: thanks for response, but it doesn't help :-( Another thing that I notice, the floor not only gets darkened, it also receives coloring from clear color, if that makes sense. Does anybody have an idea? If that's true, it sounds like you're not seeing the floor at all. That is, you're seeing the back of the floor, which is getting culled by backface culling. A quick way to check for this is to disable backface culling on your scene (look at osg/CullFace). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lightning problem with camera point of view
Jean-Sébastien Guay wrote: I imagine that any modeling software should have a tool to generate/smooth normals. 3DS Max, Blender, Maya, ... It's pretty basic functionality. In Creator it's called Calculate Shading, but it may be called something else in other modeling software. I think 3ds Max calls them smoothing groups. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New ffmpeg plugin checked into svn/trunk
Robert Osfield wrote: This doesn't solve the problem of providing the audio sink though... only possibility would be to have osgmovie use something like SDL to provide the audio, or we could even provide an option in the plugin to use SDL. SDL on macs plays silly games with Cocoa though so you end up odd dependencies even if you don't use video so I'm not convinced this is a clean solution as it could be. So members of the community, what audio libraries should be on our list of targets? Do we even go as far as integrating osgAL/osgAudio directly into the core just to enable this plugin to gain the option of audio? OpenAL is an obvious possibility for this. The OpenAL-Soft implementation at http://kcat.strangesoft.net/openal.html supports almost all of the platforms that OSG supports, and there are also hardware implementations of OpenAL for some sound cards (mostly Creative Labs). There is also a dedicated OSX implementation. You wouldn't necessarily need to go so far as to integrate osgAudio yet. Simple streaming from ffmpeg could probably be implemented with just a few lines of OpenAL code. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: One technical feature I can think of is that OGL is cross platform, running on everything from supercomputers to hand-held devices. D3D is a NO-OP in this regard. That alone should rule out D3D as far as OSG is concerned. That's not true at all! D3D is cross-platform! It works on Windows *and* XBox 360! (I've actually seen Microsoft call this cross-platform in the developer docs. Seriously.) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openscenegraph.org stats
Robert Osfield wrote: I would just love to get open source OpenGL drivers to a point that they match the proprietary ones on all platforms, once you get to this point there is no turning back, the open source development model will just outpace the proprietary solutions in terms of features and stability. Both ATI and Intel have already published lots of specs on their hardware, and Intel and ATI open source drivers are under development, but it takes time to get a fully operational driver in place, so we do need to be patient. It's good to hear of success with the Intel drivers already. If only NVidia would follow suit and be more open about their hardware then we'd have potential for OpenGL drivers to all come out of hiding. Anybody ever try the nouveau driver for Nvidia cards? http://nouveau.freedesktop.org/wiki/ --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New ffmpeg plugin checked into svn/trunk
Robert Osfield wrote:
Hi Jason,
On Thu, Feb 26, 2009 at 9:10 PM, Jason Daly jd...@ist.ucf.edu wrote:
OpenAL is an obvious possibility for this. The OpenAL-Soft implementation
at http://kcat.strangesoft.net/openal.html supports almost all of the
platforms that OSG supports, and there are also hardware implementations of
OpenAL for some sound cards (mostly Creative Labs). There is also a
dedicated OSX implementation.
You wouldn't necessarily need to go so far as to integrate osgAudio yet.
Simple streaming from ffmpeg could probably be implemented with just a few
lines of OpenAL code.
Do you have any links to a tutorial that illustrates what these few
lines of code might be?
No, but off the top of my head:
// Opening the device looks like this:
ALCdevice * device = alcOpenDevice(NULL);
ALCcontext * context = alcCreateContext(device, NULL);
alcMakeContextCurrent(context);
alcProcessContext(context);
// Set the distance model to NONE, so there is no distance
// attenuation
alDistanceModel(AL_NONE);
// Initialize the listener's state
ALfloat orientation[6];
alListener3f(AL_POSITION, 0.0, 0.0, 0.0);
alListener3f(AL_VELOCITY, 0.0, 0.0, 0.0);
alListenerf(AL_GAIN, 1.0);
memset(zero, 0, sizeof(ALfloat) * 6);
alListenerfv(AL_ORIENTATION, zero);
...
// Setting up playback with a double-buffered streaming mechanism looks
like this:
ALuint buffers[2];
ALuint source;
alGenBuiffers(2, buffers);
alGenSources(1, source);
alBufferData(buffers[0], AL_FORMAT_MONO16, audioData, dataLength, 48000);
alBufferData(buffers[1], AL_FORMAT_MONO16, audioData, dataLength, 48000);
...
// This is how you keep the buffers full
alGetSourcei(source, AL_BUFFERS_PROCESSED, processed);
if (processed 0)
{
// Swap the buffers
buffer[0] = buffer[1];
// Fill the back buffer again
alBufferData(buffers[1], AL_FORMAT_MONO16, audioData, dataLength,
48000);
}
OK, maybe it's more than a few lines, but it's pretty straightforward.
If I had more time, I'd contribute it myself. I'm sorry that I can't
spare the time right now.
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New ffmpeg plugin checked into svn/trunk
Robert Osfield wrote: Do you have any links to a tutorial that illustrates what these few lines of code might be? Also if anyone's interested, you can find the OpenAL spec here: http://connect.creativelabs.com/openal/Documentation/OpenAL 1.1 Specification.htm --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New ffmpeg plugin checked into svn/trunk
Robert Osfield wrote: Hi Jason, Thanks for quick tutorial :-) I've just checked in what will be the interface for getting audio data from a ImageStream, bascially we have two new pure virtual base classes osg::AudioStream (that handles the reading of the audio data) and osg::AudioSink(Interface) that will be subclassed to integrate the audio library that will render the audio - this is where OpenAL/SDL etc would come in.One attaches the AudioSink to the AudioStream to wire up the reading to the playing. So, is it your intention that the AudioSink interface would be implemented by another plugin (e.g.: an openal plugin)? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openscenegraph.org stats
Jean-Sébastien Guay wrote: Yes, I guess that's where my confusion stems from too. I always thought an actual standard had to be ratified by an independent standards body (ANSI, ISO, CSA here in Canada, ...). In this view, a company or consortium of companies could not unilaterally say that something is a standard. Wouldn't that lead to everyone saying that what they do is standard? What standards body ratified TCP/IP? ;-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
Robert Osfield wrote: On Fri, Feb 27, 2009 at 7:29 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC shayne.tuel...@hill.af.mil wrote: It works on Windows *and* XBox 360! Hmmm...is that really cross-platform since the embedded OS on Xbox 360 really has its roots in Windows 2000? I think the statement might have been a playful one... ;-) It was. I literally laughed out loud when I saw the claim in the developer docs. I think I was reading the docs for XAudio2 at the time. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openscenegraph.org stats
Jean-Sébastien Guay wrote: Hi Jason, What standards body ratified TCP/IP? ;-) Hmmm, getting even more off track here, but as far as I know TCP/IP is not a standard (other than a de facto standard, which it certainly is). It's defined by RFCs and not a standard. So it's ratified by no standards body since it's not a standard. Well, if I can't get you to call TCP/IP an open standard, I'm out of ammo... ;-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openscenegraph.org stats
Jean-Sébastien Guay wrote: And what's more, I actually have two nostalgia machines which I plug in once in a while. The first has a Cirrus Logic CL-GD5428 card (1MB, yessir), and the other has a Voodoo2 12MB. I'll probably keep those till I die, just because that was the time when it all started for me, even though every time we move my s/o asks why I waste space with those old computers... Ever try DosBox ( http://dosbox.com/information.php?page=0 ) ? I was trying to set up a nostalgia machine as well, but I kept having problems with my old hardware. Then I found DosBox, and realized how pointless my efforts were. I guess it depends on *why* you have it around, though. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openscenegraph.org stats
Jean-Sébastien Guay wrote: Hi Jason, Ever try DosBox ( http://dosbox.com/information.php?page=0 ) ? Yes, of course, but running it on the real hardware is its own reward. :-) Of course, like I said, it depends on *why* you keep them around. Mind you, I haven't thrown my hardware away, either :-) Plus, I hate how nothing in DosBox really runs that well (even something that ran well on a 486DX/33 has trouble in DosBox, and I have to spend about 5 minutes each time finding the right settings...). So I prefer keeping the machines around, getting them out every year or so when I feel like it and having things run exactly like they used to. In my case I had better luck with DosBox than with the old hardware. It even runs Wing Commander III pretty well on my PC. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New ffmpeg plugin checked into svn/trunk
Robert Osfield wrote: Hi Sukender, The needs for the providing audio for movies read by the ffmpeg is that we have a AudioSink implementation that can pull the data from osg::AudioStream and play it. We don't need a scene graph node, or reading support for the ffmpeg plugin as it stands. I'm basically working to get the present plugin up to feature competitive for first the xine-lib plugin and later hopefully the quicktime plugin. FYI, the ffmpeg has ogg support available - in fact I'm just download a .ogg movie for testing. I would be not be surprised if we could get it handle the audio reading as well. In my experience, ffmpeg will decode just about anything you throw at it. It shouldn't even break a sweat on a Vorbis stream. I think most of osgAL would be superfluous here. We don't need spatialization or decoding. The only thing we'd use is the interface to the audio hardware. I guess the question becomes whether it is worth it to use osgAL (which uses OpenAL++, which in turn uses OpenAL), or whether it would be better to just write an OpenAL implementation for AudioSink and make it a plugin (much like the freetype plugin is a concrete implementation of osgText::Font::FontImplementation). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FFmpeg has a stable release!! 0.5 is now out the door
Robert Osfield wrote: Hi All, After getting used to the idea that FFmpeg was a wacky project publicly committed to not providing stable releases that have done the unthinkable - they've gone and made a stable release! Check the front page of http://ffmpeg.org/ out. Inconceivable! The last stable release was in September of 2003! Well, better late (five years late), than never, I guess! :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glActiveTextureARB in OSG
Robert Osfield wrote: Hi Martin, The OSG queries OpenGL extensions at runtime, so even if the header doesn't contain the function then it'll be able to pick it up from the driver. As a general note, I'd recommend avoiding calling OpenGL yourself, and port your code across to using the OSG classes to do the OpenGL work, this will avoid issues with clashes of state managment and allow the OSG to do state sorting + lazy state updating, and it'll do the extension setup for you. Hi, Martin, First read and consider Robert's warning above (to me, it seems that switching the active texture unit in the middle of a traversal is just asking for trouble). Next, have you tried using just glActiveTexture() (without the ARB)? glActiveTextureARB() is the function from the ARB_multitexture extension. Since OpenGL 1.3, multitexture has been part of core OpenGL, and the core function is just glActiveTexture(). 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] Can 3DS model in Parent-Child Mode be read inParent-Child mode?
Ümit Uzun wrote: Hi All, I have an model and this model has kind of parts. I am not a modeler so this question might be so stupid :) Before I have read the model and find all parts by nodeVisitor and recreate the scenegraph in parent-child mode and then I have manipulate all transformation in inheritance. I mean when I rotate some part, the other childs rotate too. But when I directly read 3DS model and not recreate the scene graph the parent-child relation doesn't exist on graph although I have already regenerate the model on 3DMAX in parent-child mode as you can see from the attached image. At this point, Can't we read 3ds model which organized parent-child mode directly and create our scene graph in this mode or not? I can't achieve this relation between model's parts. I think 3ds is just a geometry format, and doesn't have support for hierarchical models (somebody please correct me if I'm wrong). Probably the best way to get what you need to get the OSGExp plugin for 3ds MAX, and export the model directly as a .ive file. If you have the COLLADA-DOM set up for OSG, you could also try exporting from 3ds MAX to a COLLADA (.dae) file. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DoomLike manipulator
Simon Loic wrote: Glad to see that this manipulator generates interest. Concerning the name, the manipulator is designed as explained in the header : The camera control is done via keyboard arrows concerning the position and via mouse draging concerning the orientation. There are two modes : the horizontal and the free. In the free one the translation direction is exactly aligned with the view direction and thus can span the whole set of direction. In the other, the moving direction is constrained to remain horizontal. Note : horizontal mode is not implemented yet!! Taking into account what you said, Sukender, we should call it FirstPesonManipulator and call the two modes GENERAL and DOOMLIKE. What do you think about this? I wouldn't call it DOOMLIKE for two reasons. First, DOOM's mouse controls didn't work this way (the Y-axis on the mouse was used for forward/backward motion, since you couldn't look up/down in DOOM). Second, I don't think it should be named based on whatever game happened to use it in the first place. If someone hasn't played that particular game, that name won't mean anything to them. How about GENERAL and GROUNDED instead? By the way, does this manipulator include collision and terrain following (specifically in what I'm suggesting calling the GROUNDED mode)? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DoomLike manipulator
Sukender wrote: And about the modes, I would prefer FREE and HORIZONTAL :) My preference would be GROUNDED (as in, you stay on the ground) rather than HORIZONTAL. To me HORIZONTAL kind of implies one-dimensional motion. I'm indifferent on FREE vs. GENERAL. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DrawElements* memory management
Paul Martz wrote: Ignore this post. The answer is: DrawElementsUInt is a VectorGLuint. Of course, I had to post and show my ignorance first before I figured that out. :-/ Good. For a minute there, I thought I was 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] ShadowMap Required OpenGL Extensions
Ben Axelrod wrote: I should probably specify the graphics cards in question. The working card is a NVidia 7300 LE. The card that passes the test, but still does not work is a NVidia NV37GL [Quadro FX 330/Quadro NVS280] (rev a2) The NV37 is a GeForce 5-era card, so it should fully support programmable shading, although there were limits on how long and/or complex the shaders could be. I wonder if you're running into a shader instruction limit or something like that. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap Required OpenGL Extensions
Ben Axelrod wrote: Thanks, Do you think that changing the shadow texture size will have any affect here? I have noticed a somewhat similar failure of ShadowMap when I have a very large mesh file, and decreasing the shadow texture size seems to fix that. Oh, possibly. The GeForce 5's might have had a smaller max texture size, too. It's been a while, so I don't remember the numbers exactly. In general, though, they had tighter limits than the modern cards. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blend Equation and multipasses
paulo wrote: Hi, To use a mutipass I need to turn on blending. (at least with open gl) Is it also needed with osgFX or is it automatic? I tried adding a BlendEquation object to my stateset, but I could not figure out which symbolic constant corresponds to the gl functions glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); blendFunc = new osg::BlendFunc(); blendFunc-setFunction(osg::BlendFunc::SRC_ALPHA, osg::BlendFunc::ONE_MINUS_SRC_ALPHA); stateSet-setMode(GL_BLEND, osg::StateAttribute::ON); stateSet-setAttributeAndModes(blendFunc, 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] Testing of OSG and VPB SVN in prep for 2.5.3 devreleasese
Jean-Sébastien Guay wrote: Wow, many thanks for testing across all these combinations. Now will anyone else pitch in for other platforms?? :-) Red Hat Enterprise 5.2 32-bit, g++ 4.1, cmake 2.4.5 Pentium D 955, Nvidia 7950GX2 on 169.12 drivers Builds and runs fine, although I had to manually specify CXXFLAGS=-march=i686 as an environment variable to get the new atomic ref counting to work properly. Without that, it failed the atomic tests. I tried specifying the architecture inside ccmake, but it seemed that once the test failed, it never ran it again (I don't know if there's a cmake-specific command line option that would work). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for2.5.3 devreleasese
Jean-Sébastien Guay wrote: That seems to be a common problem right now, hopefully someone with more CMake knowledge will be able to suggest a way to circumvent that. But it seems (from some reports) that deleting your CMakeCache.txt (in your build directory) would force the tests to be re-run. Right, my point was that unless I explicitly specified -march=i686 in the CFLAGS (or CXXFLAGS, I forget which) environment variable, the test would fail every time I ran cmake or ccmake. Even if I changed the CFLAGS (or CXXFLAGS) inside of ccmake, the test wouldn't be run a second time to fix the problem, so I had to set the -march flag in the environment before running cmake or ccmake. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3devreleasese
Robert Osfield wrote: Hi Jason, Mathias has submitted some changed to the cmake Atomic checks/setup, I have now checked these into SVN. Could you do an svn update and clean build, then let us know if it compiles OK now. Hi, Robert, Just updated. Now, if I don't do anything to the environment, it settles on USE_MUTEX. This is an improvement (it previously didn't pick any method). I still have to set CXXFLAGS=-march=i686 in the environment for it to pick USE_GCC_BUILTINS. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multitextureing coordinates
Peter Wraae Marino wrote: Hi users, I have create simple quad using osg::Geometry and I would like to apply multitextering to it. I'm missing a way to set glMultiTexCoord using OpenSceneGraph. Is there a way one can set glMultiTexCoord? Look at osg::Geometry::setTexCoordArray() You can set a different texture coordinate array for each texture unit. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RE : multitextureing coordinates
Peter Wraae Marino wrote: Hi Franclin, Yea doing it using a shader is easier and more flexible, but is there a reason why we don't get access to do multitexture coordinates? Jasons suggestion: osg::Geometry::setTexCoordArray() is not for multitexture coordinates, so I can't really use that. I use it for multitexture coordinates all of the time. Why would you think it doesn't work? --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
[EMAIL PROTECTED] wrote: Right. Curious (this is probably just semantics)... if I had an out-the-window view and an inset bird's-eye view (same scene), would one think of this as a single conceptual view as it's all looking at the same scene? I see now how this could be done in either Viewer or CompositeViewer, but just curious as to what such as setup is considered conceptually. I believe the intent would be to use CompositeViewer for that. Even though you're looking at the same scene with both cameras, they're really two distinct views. It's not as if your bird's eye view is a part of (or a slave to) the out-the-window view. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Coordinate system mapping from WTK to OSG...
[EMAIL PROTECTED] wrote: So, if anyone out there has experience of mapping from WTK to OSG, specifically in regards to what should happen to rotation angles, and quarternians, I would be most grateful - and perhaps my wall could then be repainted beige instead of red ;-( I don't know about OSG to WTK specifically, but I might have a suggestion. When translating an orientation (or more specifically, a rotation) from one coordinate system to another, the correct procedure is to first convert from your target coordinate system to your original coordinate system, then apply the rotation, then convert back. So -1 R' = M * R * M Where R' is the desired rotation in OSG coordinates, R is the rotation in WTK coordinates, and M is the conversion matrix (or quat) from WTK coordinates to OSG coordinates. Now, usually when I explain this, I get the ordering wrong, so if it doesn't work first try, just try reversing the order :-) 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] FPS Motion Model
Robert Osfield wrote: Hi Judd, The OSG just adapts the windowing systems provided mouse xy values, and as such is limited to the clapping that happens due to the windowing systems. Getting the delta moyse xy isn't supported, and personaly I don't know how one would go about getting this extra info from the various window systems, I'm open to suggestsions. The way we handled this is to provide wrapping of the mouse to the other side of the screen/window when the pointer gets within a few pixels of the edge. The pointer values are returned as normal (and reflect the change in position), but the delta values stay consistent (the pointer position is tracking internally and the extra movement from the warp is subtracted out). For us this provided nice, smooth delta values that we used to create an FPS motion model (among others). We just had to add a couple of extra functions to enable/disable the wrapping behavior (not everyone will want it), and we also had to implement grabbing of the pointer (restricting it to the window) for windowed applications, otherwise it was possible for the pointer to leave the window if you moved it fast enough. Unfortunately, none of this code was implemented in OSG, so I can't contribute it (and I'm not in a position where I can port it right now). Maybe the idea will work for someone, though. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer's turns up black when run from differentthreads.
David Johansson wrote: Hi Robert, This does nothing i'm afraid. nvidia-xconfig --sli=Off followed by a restart of X.. Not sure if this helps or not, but you have to use the multigpu option with the 7950GX2, not the sli option. multigpu is for SLI with two GPU's on one card, while sli implies the two GPU's are on separate cards. For some reason, there's a difference (check /usr/share/doc/NVIDIA_GLX-1.0/README.txt for details). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer's turns up black when run fromdifferentthreads.
David Johansson wrote: Hi Jason, Setting multigpu did nothing either. You don't happen to have the same card and can test my code posted earlier? I can probably do that. I'm not sure when I'll get the time, but I should be able to find some this week. It might take a little while because I'm still on OSG 2.2 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] osgViewer's turns up black when run fromdifferentthreads.
David Johansson wrote: Hi Jason, Setting multigpu did nothing either. You don't happen to have the same card and can test my code posted earlier? Hi David, I gave it a quick try with OSG 2.2, and I'm definitely seeing problems. After I open the second viewer, if I alt-tab back to the first, I sometimes get a brief lock-up with the mouse pointer (I've seen this when running multiple OpenGL contexts before, even with something as simple as glxgears). More to the point, occasionally, the first window is black, and other times, I seem to get a residual display (as if the frame-buffer isn't fully cleared). Fyi, I'm running RHEL 5.2 with a 7950GX2 (SLI/MultiGPU disabled) with the 169.12 driver. --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 Monitor VideoMemory usage
Bob Balfour wrote: I've used RivaTuner to monitor video memory usage on WinXP, but it doesn't do it on Vista (it says due to Vista's virtualization of video memory?). Does anyone know of a way to monitor video memory usage on WinVista? I have a very choppy scene (using quad-core HP, 2 Nvidia GTX8800, Vista, multi-thread OSG2.4-based app), and I suspect its due to texture overload. Whatever Vista is virtualizing didn't seem to help! You probably need something like gDEBugger that can talk to the video card's performance counters directly. Unfortunately, it isn't free, but you can get a free 30-day trial to see if it works for what you're trying to do. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Another case for extendable plugin loaders... Was Re:DDS textures flipped on flt files
brettwiesner wrote: Hey, Since most DDS textures are going to come in flipped (ie: directX style and not openGL style) I would like my application to always pass the dds_flip option to the DDS loader. If I could extend the DDS loader I could do that. Just another case for including the loaders as actual libs and the plugins themselves as smaller projects that just use the loaders api. It's easy enough to hard code a ReaderWriter option: options = new osgDB::ReaderWriter::Options(dds_flip); texImage = osgDB::readImageFile(filename, options); You might want to use a ref_ptr for the options object, but basically, the above should work. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Turn off Automatic Units to Meter convertsion
Geoff wrote: I am wondering how I can turn off the automatic Units to Meters conversion that is taking place when I load my OpenFlight file into a osg:::Node. My file is in Feet, which is what my program uses, and I would like to use some of my old code that uses feet without having to do the conversion myself. Pass the option noUnitsConversion to the loader, and it should refrain from doing the conversion. Alternatively, you can pass convertToFeet, and everything will be converted to feet instead of meters. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Turn off Automatic Units to Meter convertsion
Paul Martz wrote: By default, the FLT loader does not convert. So, if you are expecting feet but appear to be getting meters (everything is about 1/3 the size you expect) then the header of your FLT file probably has an incorrect value in the units field. If true, this is a problem with your model and not a problem with OSG. Paul, This line of code (from ReaderWriterFLT) appears to contradict what you're saying: document.setDoUnitsConversion((options-getOptionString().find(noUnitsConversion)==std::string::npos)); // default to true, unless noUnitsConversion is specified. My experience has always been that the FLT loader converts to meters by default. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighted baked models....
Kim C Bale wrote: So... after much clawing and gnashing of teeth I found this little beauty: http://www.feelingsoftware.com/content/view/65/79 It’s a freeware Collada exporter for MAX 2008 and that works every time. I believe someone has compiled a version that works with 2009 which you can find here. However, I’ve not tried it. I was going to suggest the Collada route via the Feeling Software exporter as well. It's far and away the best Collada exporter for MAX that I've used (I've tried a few). I'm 90% confident that all of the information you need will make it into the .dae file from MAX. I'm not sure how well OSG's Collada loader will deal with it, but at least you have the code to fix it, if necessary :-) Just a heads-up... When you go to export from MAX, make sure you use the Feeling Software exporter, and not the Autodesk FBX/Collada exporter. That cost me about an hour one time. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] read file Collada using osg
Adonai Canêz wrote: Hi, I'm don't find source of collada in www.collada.org http://www.collada.org, what is location download? The library is called the COLLADA DOM. You can find it here: http://sourceforge.net/project/showfiles.php?group_id=157838package_id=270665release_id=596687 --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance expectations
Jan Ciger wrote: Guys, just out of sheer curiosity - what kind of HW is needed to generate such framerates? If you cannot talk about specifics, at least a ballpark idea would be cool to know. Sounds like a haptic device to me. Realistic haptics require force computations (and hence, collision detection) to be done at 1000 Hz or so. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GTK guru's please help!
Jeremy Moles wrote: I've always been under the impression that gtk_init() has to be called first before any fuction that begins with gtk_*, have you tried moving it as the first call instead of disable_setlocale? What if you call gtk_init() in the main code before doing anything that forces the loading of the plugin? Yeah, gtk_init() definitely needs to be the first GTK call you make. I've also run into problems with GTK managing resources in one thread and GLX resources being created or destroyed in another thread. I'm not sure that's what's happening here (I got crashes, not hangs), but it might be worth mentioning. The only other thing would be to make absolutely sure that all of the GTK calls are done from one thread. GTK *cannot* be multi-threaded under windows, and it requires some special handling under other OS's. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture coordinates question
Argentieri, John-P63223 wrote: Gentlemen, Is there a way to force vertex B to have a different texture coordinate in each of triangle ABC and triangle BCD? Texture coordinate indices? I don't understand how those are applied. If the binding is per_primitive, will each of my triangles be textured by a single pixel? PER_PRIMITIVE texture coordinates aren't allowed (only PER_VERTEX, or none at all). Also, you don't want to use texture coordinate indices because they'll knock you into immediate mode (slow) rendering. The easy way to get what you're looking for is to have arrays like this: vertex array: vA, vB, vC, vB, vC, vD texcoord array: tA, tB1, tC, tB2, tC, tD where tB1 != tB2 and use a DrawArrays primitive set (ie: don't use DrawElements). In other words, just duplicate the vertex positions explicitly in your vertex array, and make the corresponding texture coordinates whatever you need them 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] OpenSceneGraph-2.1.3 dev release made
Jean-Sébastien Guay wrote: That's probably a bug in the CMake files actaully. Cygwin is a Unix clone running on Windows, and Unix will never have wsock32.lib. Only Win32 and MinGW targets should be using that library. So there needs to be a conditional to exclude wsock32.lib on Unix/Linux and Cygwin (or include it on Win32 and MinGW, not others). If the Win32 API is installed (as it typically is), there should be a libwsock32.a. The link line should use -lwsock32, not -lwsock32.lib -- --J I'm a castaway stranded in a desolate land, I can see the footprints in the virtual sand. --Neil Peart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linux ATI driver improvements!
Ulrich Hertlein wrote: Speaking of which, can anyone recommend a good Linux/nvidia laptop? It seems like most of the laptop you get nowadays are either ATI or intel... I use a Dell Precision M90, and love it. You get a choice of nVidia mobile Quadro cards. The new Vostro's look pretty cool too. The 1700 comes with a GeForce 8600M GT. ./ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- --J I'm a castaway stranded in a desolate land, I can see the footprints in the virtual sand. --Neil Peart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] depth buffer - real pixel z - depth
zarrandreas wrote: Hi, I render depth buffer to the image, but values I have there are between [0.0, 1.0]. How can I get real z-depth? This page explains a simple conversion pretty well: http://www.cs.unc.edu/~hoff/techrep/openglz.html --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-users Digest, Vol 4, Issue 3
Robert Osfield wrote: On 10/2/07, Abe Stephens [EMAIL PROTECTED] wrote: Robert: What should we expect from the collada import (or from other paths into OSG)? Obviously we'd need to investigate collada export from a modeling tool separately. I'm not th author or a user of COLLADA so the contributors to COLLADA will have to answer this. I'm not a dae plugin contributor, but I'm somewhat familiar with COLLADA. As far as I can tell, there is no support for any kind of animations in the OSG COLLADA reader, only the basics (visual scenes, nodes, geometry, transforms, and materials). It appears to support skin and morph controllers as well, but not the animations to manipulate them. Hope this helps, -- --J I'm a castaway stranded in a desolate land, I can see the footprints in the virtual sand. --Neil Peart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgSim::OpenFlightOptimizer
Paul Martz wrote: Can anyone tell me what this is used for, if anything? As far as I can tell, no code references it. Is it intended for application use, and not used internally in OSG? IIRC, it was used at one point by the newer OpenFlight plugin to handle some of the lower-level optimization (things that the regular Optimizer couldn't do). I don't recall what eventually happened to all of that, (it's probably in the archives somewhere, but I couldn't tell you the date). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Restoring Mouse Pointer
maruti borker wrote: I am trying to develop a normal walkthrough program in OSG . I am trying use wasd for movement and mouse for rotation . W-front A-left D-right S-back . The wads part is done , but when it comes to mouse movement i am facing a small problem . What i am trying to do is , i am calculating the change in x co-ordinate and y co-ordinate of the mouse while it is moving . And i am rotating according to value of dx and dy .I was able to do it quite sucessfully .. but then i faced a problem . The problem as that i couldnt rotate more when the pointer is at a corner . coz near the corner he cant move further and dx=0 or dy=0 . Thus i wasnt able to move anything :( . so i thought of restoring the mouse pointer every frame to the center of the window. For that i used requestWarpPointer() of osgViewer::GraphicsWindow . But now the program is behaving weirdly ... can u please check it out .. thanx in advance Most likely the requestWarpPointer() call is generating a mouse movement event that is confusing the viewer. A quick, hacky way to check this is to look at the new pointer position and ignore the event if it's exactly at 400,400 (make sure you call getX/getY, instead of getXnormalized,getYnormalized). If this is the problem, you'll either have to figure out a different way to do this, or somehow detect whether the event came from a real mouse movement, or a warp pointer call. The way we've done this is in the past to do wrapping of the pointer. When the pointer gets within X pixels of the side of the screen, warp it to the other side. Of course, we had the advantage of doing our own low-level event handling, so we knew for certain when the pointer was moved. You might get away with the same thing just by looking at the delta (just ignore the movement if the delta is greater than some value), but this could be error-prone. -- --J I'm a castaway stranded in a desolate land, I can see the footprints in the virtual sand. --Neil Peart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vertex Shader Attributes
Schmidt, Michael M wrote: Hi, I was trying to use gl_SecondaryColor to pass in a vertex position offset. However, I noticed strange behavior. Does anyone know if gl_SecondaryColor gets clamped to some value? Based on your code, why not declare: attribute vec4 centerPoint; in your shader and use it that way? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Jan Ciger wrote: However, it doesn't solve any of the animation and skinning issues and is completely useless by itself. I cannot imagine somebody bringing it up to speed with other kits from this alone, for that you need something actually usable to start from. This is why e.g. osgCharacter is a toy only - it does exactly this. You could display a stick-figure character, but that would be about it. I do not see why somebody would spend time on this when he can use osgCal or Replicant that work already? osgCal/Replicant are great, provided that you want to use Cal3D characters only. I don't think the idea behind osgSkeleton is limited to a transformation hierarchy. Most OSG users know we already have that functionality. My understanding is that osgSkeleton would provide the necessary infrastructure for skinning and character animation, and the required data could come from Collada, Cal3D, or whatever other plugin that can provide it. Or, as mentioned, the data could be created on the fly in code. That's the main advantage I see in creating a new nodekit. It makes the rendering orthogonal to the data format. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Richard S. Wright Jr. wrote: Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Negative numbers also work for render bins. You can use -10, for example, to get it drawn first. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
