Re: [osg-users] Oculus+OSG
Hi, On Thu, May 21, 2015 at 2:20 AM, Björn Blissing bjorn.bliss...@vti.se wrote: Hi again, I have finally been able to solve the last piece of the puzzle. This means that for Oculus SDK v0.5.0.1 the examples can do both client- and SDK based distortion rendering. The v0.5.0.1 version of the Oculus SDK is also the last version with support for Linux and Mac, due to the fact that Oculus has halted (the official wording is paused) development of the SDK for all platforms but Windows. This version is also the last version with client distortion rendering support. Now I focus my efforts on getting support for the latest SDK version v0.6.0.0. This version contains some major changes which will require some major refactoring on my part as well as some new features that will have to be integrated (i.e. the new layers concept). Could you branch/tag the new Windows-only code into a separate branch, please? It would make life easier for the folks like me who have the older DK1/DK2 HMDs and need it to work on Linux/Mac for example. rant It is really unfortunate that Oculus is making the integration of their stuff harder and more complicated with every SDK revision instead of the opposite :( I am seriously starting to look at the alternatives now, the Oculus kit is becoming way too much pain to deal with and for little benefit. I also wonder how is the OpenHMD (http://openhmd.net/) effort doing - the last I have looked they had DK1 support, now they seem to have DK2 as well, but no positional tracking support. However, there seems to be some impressive independent work being done on that here: http://doc-ok.org/?p=1095 There is also OSVR which includes HMD support, but I believe they have only plugins using the official SDK (?) So in the end, it might be possible to have a fully independent, open and *sane* SDK even for Oculus. /rant J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate geometry from a digital elevation model
As our application will also have to do physical simulations based on this height field data, I do not want to use external tools to do the conversion into an OSG model here's a minimal example for the HeightField / ShapeDrawable method http://snipplr.com/view/30974/osg-height-field-example/ here's a minimal example for the Delauney method (minus the loading of the image and texture) https://github.com/xarray/osgRecipes/blob/master/cookbook/chapter10/ch10_01/delaunay.cpp I guess I will just try both methods. The only missing piece seems to be a loading function or plug-in for height field Files in .asc format. But the format is trivially simple. 2015-05-21 9:26 GMT+02:00 Sebastian Messerschmidt sebastian.messerschm...@gmx.de: Hi Christian, Have you checked if osgdem supports it? I think it will happily convert anything into osgTerrain which can be interpreted as height data by gdal ... Hi, I am currently wondering which is the better way to go from a simple digital elevation model (ESRI ASCII Grid format) to a geometry. The model has a very limited area and resolution. These are the two methods I find feasible with stock OSG features: Either I could feed all the 3D points on the grid into the osgUtil::DelaunayTriangulator. However I noticed this class generates normals that require a BIND_PER_PRIMITIVE - possibly causing a fallback to the slow rendering path. Alternatively I could put the data into an osg::HeightField and use a ShapeDrawable to display it. Which of the two methods is perferable from a performance standpoint? What I would like to get is a bit of a simplification of the geometry, where larger triangles are used in areas with less surface features. Which of the two methods can provide this? I do not want to use osgEarth, as it is a bit too big in scope for my purpose and it has a lot of extra dependencies. Christian ___ osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] Generate geometry from a digital elevation model
Hi Christian, The osgTerrain::TerrainTile has direct support for rendering field fields. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate geometry from a digital elevation model
Am 21.05.2015 um 09:37 schrieb Christian Buchner: As our application will also have to do physical simulations based on this height field data, I do not want to use external tools to do the conversion into an OSG model Okay, but I would not consider it an external tool but an extended part of osg. osgdem saves you the pain of constructing osgTerrain tiles yourself. This will still won't save you the effort of reading the file, putting into the correct reference-frame etc. here's a minimal example for the HeightField / ShapeDrawable method http://snipplr.com/view/30974/osg-height-field-example/ here's a minimal example for the Delauney method (minus the loading of the image and texture) https://github.com/xarray/osgRecipes/blob/master/cookbook/chapter10/ch10_01/delaunay.cpp I guess I will just try both methods. The only missing piece seems to be a loading function or plug-in for height field Files in .asc format. But the format is trivially simple. You can of course try those, but why investing hours of work, if there is a simple ready to use solution? (getting and compiling osgdem is a matter of minutes) If you want me to, I can check if osgdem will compile thes ASCII grid format (If you can point me to a sample set). Cheers Sebastian 2015-05-21 9:26 GMT+02:00 Sebastian Messerschmidt sebastian.messerschm...@gmx.de mailto:sebastian.messerschm...@gmx.de: Hi Christian, Have you checked if osgdem supports it? I think it will happily convert anything into osgTerrain which can be interpreted as height data by gdal ... Hi, I am currently wondering which is the better way to go from a simple digital elevation model (ESRI ASCII Grid format) to a geometry. The model has a very limited area and resolution. These are the two methods I find feasible with stock OSG features: Either I could feed all the 3D points on the grid into the osgUtil::DelaunayTriangulator. However I noticed this class generates normals that require a BIND_PER_PRIMITIVE - possibly causing a fallback to the slow rendering path. Alternatively I could put the data into an osg::HeightField and use a ShapeDrawable to display it. Which of the two methods is perferable from a performance standpoint? What I would like to get is a bit of a simplification of the geometry, where larger triangles are used in areas with less surface features. Which of the two methods can provide this? I do not want to use osgEarth, as it is a bit too big in scope for my purpose and it has a lot of extra dependencies. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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] Generate geometry from a digital elevation model
Thanks, I've just looked into the osgShadow code, in particular the Island scene that is accessible with command line option -4. This looks like a good starting point. One question remains: Which formats does osgDB::readHeightFieldFile() support currently, based on the existing plug-ins? So far I have had no success loading image files (also grayscale) images with this function. Christian 2015-05-21 9:50 GMT+02:00 Robert Osfield robert.osfi...@gmail.com: Hi Christian, The osgTerrain::TerrainTile has direct support for rendering field fields. 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
Re: [osg-users] Generate geometry from a digital elevation model
answering my own question here: it appears only the GDAL plug-in currently implements readHeightField(), not counting various archive format plug-ins such as for Zip and GZ archives, or CURL for web-acess. It appears GDAL uses an xml based metafile to reference various supported geospatial file formats. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Generate geometry from a digital elevation model
Hi, I am currently wondering which is the better way to go from a simple digital elevation model (ESRI ASCII Grid format) to a geometry. The model has a very limited area and resolution. These are the two methods I find feasible with stock OSG features: Either I could feed all the 3D points on the grid into the osgUtil::DelaunayTriangulator. However I noticed this class generates normals that require a BIND_PER_PRIMITIVE - possibly causing a fallback to the slow rendering path. Alternatively I could put the data into an osg::HeightField and use a ShapeDrawable to display it. Which of the two methods is perferable from a performance standpoint? What I would like to get is a bit of a simplification of the geometry, where larger triangles are used in areas with less surface features. Which of the two methods can provide this? I do not want to use osgEarth, as it is a bit too big in scope for my purpose and it has a lot of extra dependencies. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [GL ES2] TEXTURE_EXTERNAL_OES?
Hello, Jean!
It's possible.
You can create new class AndroidCameraTexture (etc.) inherited from the
osg::Texture2D and override method apply:
*apply(osg::State state){*
*... (see texture2d implementation)*
*glBindTexture(GL_TEXTURE_EXTERNAL_OES, texId)*
*... (see texture2d implementation)*
*}*
KOS
2015-05-19 20:39 GMT+04:00 Jean Baptiste Poquelin coudbo...@yahoo.fr:
Hello,
Is it possible to make a texture object use the GL_TEXTURE_EXTERNAL_OES
target instead of GL_TEXTURE_2D?
Thank you!
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63767#63767
___
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] Generate geometry from a digital elevation model
Hi Christian, Have you checked if osgdem supports it? I think it will happily convert anything into osgTerrain which can be interpreted as height data by gdal ... Hi, I am currently wondering which is the better way to go from a simple digital elevation model (ESRI ASCII Grid format) to a geometry. The model has a very limited area and resolution. These are the two methods I find feasible with stock OSG features: Either I could feed all the 3D points on the grid into the osgUtil::DelaunayTriangulator. However I noticed this class generates normals that require a BIND_PER_PRIMITIVE - possibly causing a fallback to the slow rendering path. Alternatively I could put the data into an osg::HeightField and use a ShapeDrawable to display it. Which of the two methods is perferable from a performance standpoint? What I would like to get is a bit of a simplification of the geometry, where larger triangles are used in areas with less surface features. Which of the two methods can provide this? I do not want to use osgEarth, as it is a bit too big in scope for my purpose and it has a lot of extra dependencies. Christian ___ 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] Problem with Shadow Map
Hi David, What happens when you run the osgshadow example? Robert. On 21 May 2015 at 00:12, David Heitbrink david-heitbr...@uiowa.edu wrote: I have added a shadow scene (using shadow map technique) to my scene graph and the shadow texture I am getting does not seem to make much sense see: https://www.nads-sc.uiowa.edu/userweb/dheitbri/shadowScene_small.jpg I turned on the debug HUD, the scene has 3 cars, on top of a white rectangle, and a smaller black rectangle above the 3 cars. The light source is above everything. I do have a shaders attached, and in this rendering I do not have the shadow texture being rendered (with a bad shadow texture the shadows do not come out right). I have my graph setup as pretty much as: Composite Viewer- Scene Root (sky box is attached here) - Shadow Scene - Regular Scene (basically everything else). I pretty much set the light, and set the texture size to 4096 x 4096, that is about it in terms of what I have set for the shadow map object. Any advice on were to begin to figure this issue out would be greatly appreciated. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63774#63774 ___ 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] View volume image on web
Hi Clement, If by volume, you mean voxels, then you're out of luck, as OpenGL ES, which WebGL relies upon, lacks of 3D texture support [1]. This is something WebGL 2.0 is supposed to solve. In the meantime, there seems to be a trick involving GLSL [2] but I didn't look deep into the code/solution. BTW, how did you use WebGL with OSG? I know of OSG.JS [3], a JavaScript reimplementation of OSG API aiming to develop WebGL applications, but that's a totally different project. [1] https://www.khronos.org/message_boards/showthread.php/7225-3D-textures-in-WebGL [2] http://gamedev.stackexchange.com/questions/34110/how-can-i-implement-3d-textures-using-webgl [3] http://osgjs.org Émeric 2015-05-21 4:30 GMT+02:00 clement@csiro.au: Hi, I saved my volume image data as dds format by using osgDB::writeImage method. Does anyone know any method to be able to show dds image on webpage? I tried webgl and it does not work. I am not sure whether webgl supports volume rendering or not. Thanks. Regards, Clement ___ 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] View volume image on web
Hi Émeric, Thanks for your information. I am thinking whether it is easy way to show the volume image on web page. I also found some examples using texture2d to form volume rendering. I may try this option. Thanks. Regards, Clement From: osg-users [osg-users-boun...@lists.openscenegraph.org] on behalf of Émeric MASCHINO [emeric.masch...@gmail.com] Sent: Thursday, 21 May 2015 18:52 To: OpenSceneGraph Users Subject: Re: [osg-users] View volume image on web Hi Clement, If by volume, you mean voxels, then you're out of luck, as OpenGL ES, which WebGL relies upon, lacks of 3D texture support [1]. This is something WebGL 2.0 is supposed to solve. In the meantime, there seems to be a trick involving GLSL [2] but I didn't look deep into the code/solution. BTW, how did you use WebGL with OSG? I know of OSG.JS [3], a JavaScript reimplementation of OSG API aiming to develop WebGL applications, but that's a totally different project. [1] https://www.khronos.org/message_boards/showthread.php/7225-3D-textures-in-WebGL [2] http://gamedev.stackexchange.com/questions/34110/how-can-i-implement-3d-textures-using-webgl [3] http://osgjs.org Émeric 2015-05-21 4:30 GMT+02:00 clement@csiro.au: Hi, I saved my volume image data as dds format by using osgDB::writeImage method. Does anyone know any method to be able to show dds image on webpage? I tried webgl and it does not work. I am not sure whether webgl supports volume rendering or not. Thanks. Regards, Clement ___ 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] View volume image on web
Hi Clement, On 21 May 2015 at 12:43, clement@csiro.au wrote: Thanks for your information. I am thinking whether it is easy way to show the volume image on web page. I also found some examples using texture2d to form volume rendering. I may try this option. Thanks. With WegGL I think the best option would be a stack of axis aligned 2D images that you render from back face to front face to build up the the 3D volume. The results won't be as good as you can do with a full Texture3D but it might be good enough. The other approach would be to create a browser plugin, then you'd have full access to OpenGL. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Oculus+OSG
On Thu, May 21, 2015 at 3:55 PM, Björn Blissing bjorn.bliss...@vti.se wrote: The head of the master branch is currently supporting the v0.5.0.1 of Oculus SDK. The work with v0.6.0.0 is currently located in a separate branch. I have not decided yet on how to proceed with the branches. I usually tag the last working commit of an SDK version before pushing commits belonging to a new SDK version. But since Linux and Mac will be abandoned, it may be a demand for a separate branch for the continuous development based on SDK v0.5.0.1. I will keep the idea in mind... I think that for the time being it is completely enough to simply tag the last good version and document the tag name somewhere, so that when someone needs it the revision can be found easily. A branch can be done at any time later, if required. Well, I guess they believe that reducing the number of accessible parts of the SDK makes the product easier to integrate. BUT as they keep closing the SDK they also reduces the ways people can use the product. They seem 100% focused on (windows) games (which maybe the smart business decision), but they leave out the people how like to hack stuff and create solutions which no one at Oculus Inc. imagined. The problem is that they are shooting themselves in the foot, even when it comes to the mainstream (i.e. game) applications. I was working quite a bit with the Unreal Engine 4 and their rendering code recently because of my work and there the Oculus integration is a token effort at best and a horrible, bolted on kludge at worst. The last time I checked (4.7.x version) there wasn't even support for the DK2 and things like post render warping yet. Perhaps this has changed in the upcoming 4.8, but I didn't have time to check so far. UE4 renders in such way that there are several rendering threads collecting rendering and compositing commands (UE4 uses deferred shading approach) into tasks and that is then queued for another thread to be actually executed by one of the RHI (D3D/GL/GL ES/...) backends. That is all happening asynchronously, in order to achieve the best performance. The engine architecture is such that integrating deeply intrusive features like the post render warping or the predistortion from the Oculus SDK is a major and messy work, having to introduce the Oculus-specific code all over the place. The SDKs my way or the highway approach pretty much flies in the face of all the abstraction and architecture work in these engines :( And that is all for a single HMD - what about Valve, Morpheus and perhaps yet another major player that could appear? All those (will) require their own hacks like this. I doubt that this is going to be a sustainable development model - the costs of maintaining the resulting code mess will be enormous. Or the engine developers end up saying that they support only HMD X on a platform Y and that's it. In the worst case the company decides that VR is so niche market that the effort to support an HMD is simply not worth it. And those are commercial developers, good luck to indies or the open source ones without the resources and access that Epic or Unity have ... Hopefully the competition will benefit the HMD manufacturer which is most open, but I guess that the winner will be the one who can provide the killer application (or in this case; the killer game). I wonder what will be the actual adoption rate by the game studios. So far there was a lot of hype, but very few have explicitly announced support for HMDs in their upcoming titles (it isn't something you can just bolt on after the fact, for both technical and usability reasons). Moreover, pretty much the only game engine on the market with good support for the Rift is Unity3D right now. And that is only because Oculus engineers are working on it, AFAIK. I guess we need to wait until the next year and see what happens once the mass market CV1 is released. J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Oculus+OSG
Jan Ciger wrote: Could you branch/tag the new Windows-only code into a separate branch, please? It would make life easier for the folks like me who have the older DK1/DK2 HMDs and need it to work on Linux/Mac for example. The head of the master branch is currently supporting the v0.5.0.1 of Oculus SDK. The work with v0.6.0.0 is currently located in a separate branch. I have not decided yet on how to proceed with the branches. I usually tag the last working commit of an SDK version before pushing commits belonging to a new SDK version. But since Linux and Mac will be abandoned, it may be a demand for a separate branch for the continuous development based on SDK v0.5.0.1. I will keep the idea in mind... Jan Ciger wrote: It is really unfortunate that Oculus is making the integration of their stuff harder and more complicated with every SDK revision instead of the opposite :( I am seriously starting to look at the alternatives now, the Oculus kit is becoming way too much pain to deal with and for little benefit. Well, I guess they believe that reducing the number of accessible parts of the SDK makes the product easier to integrate. BUT as they keep closing the SDK they also reduces the ways people can use the product. They seem 100% focused on (windows) games (which maybe the smart business decision), but they leave out the people how like to hack stuff and create solutions which no one at Oculus Inc. imagined. Hopefully the competition will benefit the HMD manufacturer which is most open, but I guess that the winner will be the one who can provide the killer application (or in this case; the killer game). Best regards Björn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63793#63793 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with Shadow Map
when I run the OSG Shadow example, it works. I also modified the example to use a composite viewer and that works as well. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63792#63792 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
