Re: [osg-users] EXTERNAL: Re: Where is CreateContextAttribs() being used?

[Lionel Lagarde]

Hi,

Win32 is the name for all the Windows windowing systems. It is used on 
all Windows (XP, 7, 10...) and on all targets (32, 64). So the

function is used.

If I remember correctly, the function is used only for >= GL3 contexts.


On 11/04/2019 14:51, Rowley, Marlin R wrote:


We are using Win10-x64.

We are trying to get RenderDoc to be able to see our application so we 
can do some graphics debugging. It’s shouting back that the current 
device context wasn’t created using CreateContextAttrib, so I started 
looking. So since we are using Win64, doesn’t look like osg will go 
the WindowWin32 route. Hmm…


How are you debugging the GPU?  It’s incredibly difficult trying to 
solve realtime pipeline problems without the use of a graphics debugger.




Marlin Rowley

Software Engineer, Staff

cid:image002.jpg@01D39374.DEC5A2E0

/Missiles and Fire Control/

972-603-1931 (office)

214-926-0622 (mobile)

marlin.r.row...@lmco.com 

*From:* osg-users  *On 
Behalf Of *Robert Osfield

*Sent:* Thursday, April 11, 2019 7:16 AM
*To:* OpenSceneGraph Users 
*Subject:* EXTERNAL: Re: [osg-users] Where is CreateContextAttribs() 
being used?


Hi Marlin,

A great for CreateContextttribs in the OSG shows:

$ grep -r CreateContextAttribs .
Binary file ./lib/libosgViewer.so.3.6.4 matches
Binary file 
./src/osgViewer/CMakeFiles/osgViewer.dir/GraphicsWindowX11.cpp.o matches
./src/osgViewer/GraphicsWindowX11.cpp:    typedef GLXContext 
(*glXCreateContextAttribsARBProc)(Display*, GLXFBConfig, GLXContext, 
Bool, const int*);
./src/osgViewer/GraphicsWindowX11.cpp: glXCreateContextAttribsARBProc 
glXCreateContextAttribsARB = 0;
./src/osgViewer/GraphicsWindowX11.cpp: glXCreateContextAttribsARB = 
(glXCreateContextAttribsARBProc) glXGetProcAddress((const 
GLubyte*)"glXCreateContextAttribsARB");
./src/osgViewer/GraphicsWindowX11.cpp:    if 
(glXCreateContextAttribsARB)
./src/osgViewer/GraphicsWindowX11.cpp: _context = 
glXCreateContextAttribsARB( _display, _fbConfig, sharedContext, True, 
contextAttributes.data() );
./src/osgViewer/GraphicsWindowWin32.cpp:extern HGLRC WINAPI 
wglCreateContextAttribsARB (HDC, HGLRC, const int *);
./src/osgViewer/GraphicsWindowWin32.cpp: 
PFNWGLCREATECONTEXTATTRIBSARBPROC wglCreateContextAttribsARB =
./src/osgViewer/GraphicsWindowWin32.cpp: ( 
PFNWGLCREATECONTEXTATTRIBSARBPROC ) wglGetProcAddress( 
"wglCreateContextAttribsARB" );
./src/osgViewer/GraphicsWindowWin32.cpp:    if( 
wglCreateContextAttribsARB==0 )
./src/osgViewer/GraphicsWindowWin32.cpp: reportErrorForScreen( "GL3: 
wglCreateContextAttribsARB not available.",
./src/osgViewer/GraphicsWindowWin32.cpp: context = 
wglCreateContextAttribsARB( _hdc, 0, attribs );
./src/osgViewer/GraphicsWindowWin32.cpp: reportErrorForScreen( "GL3: 
wglCreateContextAttribsARB returned NULL.",


So only X11 and Win32.  What platform are you using?

Robert.

On Thu, 11 Apr 2019 at 00:32, Rowley, Marlin R 
mailto:marlin.r.row...@lmco.com>> wrote:


We are trying to run the graphics debugger called ‘RenderDoc’. 
It’s spitting out an error message after we create a window and
it’s device context.  I’ve been looking through the osg code to
find a function called CreateContextAttribs().  I can’t seem to
locate it. My idea is to override where it’s used or refactor
something into the code where we can call the function ourselves.

In the meantime, I’m setting the traits->glContextVersion = “3.3”
in our graphics application but RenderDoc is still shouting
“Context not created via CreateContextAttribs.  Capturing disabled.”

-M



Marlin Rowley

Software Engineer, Staff

cid:image002.jpg@01D39374.DEC5A2E0

/Missiles and Fire Control/

972-603-1931 (office)

214-926-0622 (mobile)

marlin.r.row...@lmco.com 

___
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] Nvidia RTX

[Lionel Lagarde]

The RTX examples I found (like 
https://iorange.github.io/p01/HappyTriangle.html) use a VK command 
(similar to a compute dispatch) to trigger the ray tracing:


|void vkCmdTraceRaysNVX(VkCommandBuffer commandBuffer, VkBuffer 
raygenShaderBindingTableBuffer, VkDeviceSize raygenShaderBindingOffset, 
VkBuffer missShaderBindingTableBuffer, VkDeviceSize 
missShaderBindingOffset, VkDeviceSize missShaderBindingStride, VkBuffer 
hitShaderBindingTableBuffer, VkDeviceSize hitShaderBindingOffset, 
VkDeviceSize hitShaderBindingStride, uint32_t width, uint32_t height); |


This function posts the ray tracing command to a VK command queue. 
Finally, the main ray tracing shader "stores" the ray tracing result in 
an image using imageStore.


I don't know about mixing an OpenGL context and the VK counterpart 
(device, physical device, command queue, images...). It is maybe 
possible but like the CUDA /GL interoperability, it may require 
expansive synchronization mechanisms.



On 21/02/2019 15:19, Chris Hanson wrote:
So, you'd need a shared GL/Vk context in order to Vk load the data and 
then GL trace it, if I understand correctly?


We could probably bring VSG into play to load the data. I think 
there's enough working code there already to do so. Or, really, we 
could just us what VSG has already and compose and execute the RTX 
commands without OSG, but copying already-composed scene data over 
from the OSG side.


On Thu, Feb 21, 2019 at 3:15 PM Lionel Lagarde 
mailto:lionel.laga...@oktal-se.fr>> wrote:


Hi,

It is a GLSL extension, the ray tracing functions use some input
data (like the acceleration structure) that can only be
constructed and uploaded using the vk API.


On 21/02/2019 13:34, Chris Hanson wrote:

One of my guys pointed out this recent addition:


https://github.com/KhronosGroup/GLSL/blob/master/extensions/nv/GLSL_NV_ray_tracing.txt


On Wed, Feb 20, 2019 at 9:47 PM Chris Hanson
mailto:xe...@alphapixel.com>> wrote:


Well, I was wondering if there was an OpenGL RTX API
anywhere, but it doesn't seem there is.

Vulkan would appear to be the way to go for the future, but
since that's not ready for the oven yet (don't even have all
the mise en place), it might be we just have to make a
utility library to shovel OSG data into OptiX and let it do
the work for now. There's always going to have to be some
kind of bridge from OSG to either Vulkan or something else if
no OpenGL support extension ever appears.



-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com

<mailto:xe...@alphapixel.com> http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 •
OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP •Forensics •Imaging •UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded
• Mobile • iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel>
facebook.com/alphapixel <http://facebook.com/alphapixel> (775)
623-PIXL [7495]

___
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



--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com 
http://www.alphapixel.com/

Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • 
OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP •Forensics •Imaging •UAVs • GIS • GPS • 
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • 
Mobile • iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel 
<http://facebook.com/alphapixel> (775) 623-PIXL [7495]


___
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] Nvidia RTX

[Lionel Lagarde]

Hi,

It is a GLSL extension, the ray tracing functions use some input data 
(like the acceleration structure) that can only be constructed and 
uploaded using the vk API.



On 21/02/2019 13:34, Chris Hanson wrote:

One of my guys pointed out this recent addition:

https://github.com/KhronosGroup/GLSL/blob/master/extensions/nv/GLSL_NV_ray_tracing.txt 



On Wed, Feb 20, 2019 at 9:47 PM Chris Hanson > wrote:



Well, I was wondering if there was an OpenGL RTX API anywhere, but
it doesn't seem there is.

Vulkan would appear to be the way to go for the future, but since
that's not ready for the oven yet (don't even have all the mise en
place), it might be we just have to make a utility library to
shovel OSG data into OptiX and let it do the work for now. There's
always going to have to be some kind of bridge from OSG to either
Vulkan or something else if no OpenGL support extension ever appears.



--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com 
http://www.alphapixel.com/

Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • 
OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP •Forensics •Imaging •UAVs • GIS • GPS • 
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • 
Mobile • iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel 
 (775) 623-PIXL [7495]


___
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] OpenGL function does not return on Titan Xp

[Lionel Lagarde]

Hi,

We have a set of products based on OSG that run well on common hardware.

Recently a customer bought a NVidia Titan Xp. Our software do not work 
on this graphics card.

The software do not crash, it stop responding to any event.

The software is always stuck in the middle of a glGenTexture call 
(osg::Texture2D::apply).


We use OSG 3.0.1 but I tested with OSG 3.6.1 and the 2 have the same issue

Other graphics tools, like COIN based software or the demos that come 
with GPU Caps Viewer work fine.


The behavior is reproducible using the command "osgviewer cow.osg", and 
display the rendering stats using "s".
The stats use text, that use textures for the glyph of the characters. 
The GL function used to reserve the texture

ID  (which I think is a pure CPU/driver job) never returns.

I wonder if somebody that have a Titan Xp (I know it is a very rare and 
useless card, a 1080 Ti does the job pretty well) have a similar issue


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Read frame buffer back into main memory

[Lionel Lagarde]

Hi,

Have a look to glReadPixel. The osg::Image class has a method to read 
the frame buffer back to its own memory.



On 28/02/2018 19:05, Antoine Rennuit wrote:

Hi all,

I need to read the frame buffer back into the main memory. I know this will 
kill performance but I only need to do it once.

Is there a way to do that? I could not find clear answers on the internet.

Thanks,

Antoine.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72990#72990





___
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 setting texture min/mag filter

[Lionel Lagarde]

Hi,

The half red half black pixels may come from some kind of anti-aliasing. 
Check your frame buffer settings.


My 2 cents.


On 19/02/2018 15:18, antiro black wrote:

Hi,

Thank you for response robertos, I've been playing around with the code the last few days 
and it seems like the filters are doing something, it is just not what I expected. I'm 
wondering if I misinterpreted the meaning of a "NEAREST" filter.

As I understand it, putting both the min and mag filters on nearest means that, 
when sampling a location on your texture it will return the color of the 
nearest pixel. In other words: you will always get a value back that is present 
in the pixeldata from the image.

However, as far as I can see from my test, this is not the case: I created an image with 
red pixels on one half (255,0,0) and black pixels on the other half (0,0,0).  When 
sampling the texture to which this image was set and simply drawing the sampled values 
onto a bigger texture for debugging purposes, I see a red half, a black half and a line 
of dark red "pixels" separating them. As if the values have been interpolated 
when sampling.
If i turn off the "nearest" filters this line becomes a gradient, so clearly 
the filtering is doing something.

Am I just completely misinterpreting the intended behavior of the "nearest" 
filters? or is there something wrong in the implementation?

Thank you!

Cheers,
antiro

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72964#72964





___
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] Strange behaviour - no explanation

[Lionel Lagarde]

Hi,

The geometry state set is probably shared among several nodes.

You should clone the state set before setting the polygon mode:

if (geometry->getStateSet() && 
geometry->getStateSet()->getParents().size() > 1)

{
geometry->setStateSet(new osg::StateSet(*geometry->getStateSet()));
}

geometry->getOrCreateStateSet()->setAttribute(new 
osg::PolygonMode(osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::LINE));



On 24/01/2018 18:04, Werner Modenbach wrote:

Hi all,

I import a 3DS model and after import it shows me a flat structure of 
geodes:


Final OSG node structure looks like this:

Group

    Geode

Geometry

Geode

Geometry

Geode

Geometry

Geode

Geometry

Geode

Geometry

Geode

Geometry

Geode

Geometry

Geometry

Geode

Geometry

Geode

Geometry

Geometry

Geode

Geometry

Geometry

Geode

Geometry

    Geode

 Geometry

    Geode

        Geometry

    Geode

        Geometry

        Geometry

        Geometry

        Geometry

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

        Geometry

        Geometry

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

        Geometry

    Geode

        Geometry

    Geode

        Geometry

        Geometry

    Geode

        Geometry

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

        Geometry

        Geometry

        Geometry

    Geode

        Geometry

    Geode

        Geometry

        Geometry

        Geometry

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

    Geode

        Geometry

        Geometry

    Geode

        Geometry

    Geode

        Geometry


I do a pick with a LineSegmentIntersector.
The Interesections array contains 1 hit.
It is a geometry and has 1 parent - the geode.
I want this geometry to show in line mode.
geometry->getOrCreateStateSet()->setAttribute(newosg::PolygonMode(osg::PolygonMode::FRONT_AND_BACK,osg::PolygonMode::LINE));

But many geometries show up in line mode.
I wrote a check NodeVisitor and this visitor finds many geometries 
being set to LineMode.
I wrote another visitor which explicitely disables linemode on all 
geometries after loading of the model:

geometry->getOrCreateStateSet()->setMode(osg::StateAttribute::POLYGONMODE,osg::StateAttribute::OFF);
I already spent many hours on that but I'm running out of ideas.

Any hint from someone in the list?

Many thanks in advance

- Werner -






___
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] ViewerBase::frame() method slow after changing the color of a geometry

[Lionel Lagarde]

If you use display lists, you have to tell OSG that it has to re-build it.

If you use vertex arrays, colors->dirty() should be enough.



On 21/07/2017 12:32, Gianni Ambrosio wrote:

Thanks Lionel and Robert for the quick reply.

I tried what Lionel suggested but in fact the geometry generation is much more 
slow now.
Anyway, since I suspected that "dirtyDisplayList()" is the cause of the delay, 
I tried to remove that line but without it I cannot see the new color.
Now, is "dirtyDisplayList()" really required for what I need or is there a 
different call should I use just to see the triangle with the updated color?

Thanks,
Gianni

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=71298#71298





___
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] ViewerBase::frame() method slow after changing the color of a geometry

[Lionel Lagarde]

I don't know about the double frame but the default for geometries 
(drawables in fact) is to use OpenGL display lists (depending on the OSG 
compilation).


OpenGL display lists creation takes time. The dirtyDisplayList method 
forces OSG to re-create the OpenGL display list.



The solution is to force the geometry to use vertex arrays:

geometry->setUseDisplayLists(false);

On 21/07/2017 11:11, Gianni Ambrosio wrote:


Hi All,
I build a huge geometry (27 milion vertices, 9 milion triangles) as follows:

osg::Geometry* geometry = new osg::Geometry;
geometry->setDataVariance(osg::Object::DYNAMIC);
geometry->setVertexArray(buildVertices(count));
geometry->setColorArray(buildColors(count), 
osg::Array::BIND_PER_VERTEX);
geometry->addPrimitiveSet(buildElements(count));

On mouse event, after getting an intersection with the graphics, I do:

osg::Geometry* geom = 
dynamic_cast(intersection.drawable.get());
osg::Vec4Array& color = 
dynamic_cast(*geom->getColorArray());
color[intersection.indexList[0]] = selectedColor;
color[intersection.indexList[1]] = selectedColor;
color[intersection.indexList[2]] = selectedColor;
geom->dirtyDisplayList();
color.dirty();

The problem is that after these lines there is a delay of at least one second 
before seeing the triangle with the updated color on my 3D viewer.
Debugging OSG code I found that "ViewerBase::frame()" is called twice before seeing the new color. 
Moreover the first time "frame()" is called "renderingTraversals()" takes a lot.

I will debug the OSG code deeper but is there a way to prevent the delay I see 
in my application?
You can find the full example in attachment.

Thanks for your help,
Gianni

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=71295#71295





___
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] Test

[Lionel Lagarde]

OK.

On 03/05/2017 10:42, Robert Osfield wrote:

HI All,

Just checking osg-users/forum is still up.

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] [osgPlugins] Offline conversion to dds without gc

[Lionel Lagarde]

Hi,

Do you mean -quick ? Maybe the option has different names in the 
different version of the library.


This option force the library to use a faster algorithm to choose the 
two key colors of each 4x4 group of pixels. I do not know the real 
impact of the option.


I do not remember having performance issues. We use the API, not the 
executable. Windows is really bad at starting a lot of times the same 
program. The -list option is there to get round this issue.



On 14/11/2016 18:19, We See wrote:

Hi Lionel,

Thank you for the hint, works great (but horribly slow)! Do you know, what the 
option -fast changes?



have a look at NVidia Texture Tools (nvtt).


Cheers,
WeSee

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=69360#69360





___
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] [osgPlugins] Offline conversion to dds without gc

[Lionel Lagarde]

Hi,

have a look at NVidia Texture Tools (nvtt).

Lionel


On 08/11/2016 17:17, We See wrote:

Hi,

I try to develop a small tool for offline-conversion which converts 
openflight-files with rgb-textures into osgb-files with dss-textures. I resued 
the code of osgconv and have seen I need a graphics context for the conversion 
of textures into dds-format (class MyGraphicsContext in osgconv.cpp). 
Unfortunately our conversion-machine (virtual machine) has no 3D-graphics card, 
and therefore no graphics context.

Does anyone know a solution without the need of a graphics context?

Thank you!

Cheers,
WeSee

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=69275#69275





___
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] Support for sampler arrays

[Lionel Lagarde]

Hi,

The OpenGL command used to update a sampler* uniform is glUniformi[fv].
Sampler* uniforms are int uniforms.

An uniform of type 'array of INT' works (It works for me).

On 22/03/2016 10:36, Sebastian Messerschmidt wrote:

Hi Chris,

Hi,

Working on an app that is going to be doing a lot of work with large 
texture processing, and will need to squeeze as much data into 
graphics memory as possible and allow many textures to be referenced 
programmatically.


I've got texture arrays working, but can't use this for all 
requirements since all layers in a texture array have to be the same 
size.




It looks like I could use sampler arrays (e.g. sampler2D 
myTextures[20]; ), but osg::Uniform doesn't seem to support such a 
thing.
Arrays of samplers is used almost by no one any more. I usually use 
TextureArrays and simply resize the textures to a common size (usually 
the "biggest"). Texture arrays are efficient and easy to use.
I'd like to see the "array of sampler"-support in OSG anyways, since 
there might be situations where texture arrays are not efficient.
Another alternative are bindless textures, but we would need to add 
support to OSG too.

Last alternative could be a texture atlas.

Since you mentioned "texture processing", you might want to look into 
BufferTextures. They don't have any filtering (only texelfetch), but 
IIRC they support large amounts of texels.
So if you don't need HW-filtering/mipmapping you can use them as atlas 
textures.


Cheers
Sebastian



I'm also wondering if there's an easy way to easily run your own 
OpenGL commands in case something isn't supported yet and you just 
want to use GL directly instead of waiting for the OSG implementation?


Thank you!

Cheers,
Chris


http://www.hrwallingford.com/facilities/ship-simulation-centre 
(http://www.hrwallingford.com/facilities/ship-simulation-centre)


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66577#66577





___
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] Using a custom StateAttribute

[Lionel Lagarde]

Hi,

An attribute is identified by a type (enum Type) and a member (int). The 
StateAttribute getters and setters have the member parameter defaulted 
to 0.


I use some custom state attributes:
- I use the type as an attribute class (i.e. MATERIAL for BRDF related 
parameters...)

- I use the member of prevent conflicts with the OSG legacy attributes


On 18/10/2015 22:58, Jannik Heller wrote:

Hi,

How is one supposed to use a custom StateAttribute?

The docs say that:

"When extending the osg's StateAttribute's simply define your own Type value which 
is unique, using the StateAttribute::Type enum as a guide of what values to use"

As it is, returning a unique value simply isn't possible because the getType() 
function returns an enum:

 /** Return the Type identifier of the attribute's class type.*/
 virtual Type getType() const = 0;

Type is the enum defined here containing the default types, with no room for 
user types:


Code:

 enum Type
 {
 TEXTURE,

 POLYGONMODE,
  

 FRAME_BUFFER_OBJECT
 };




I suppose that you could choose some integer, static_cast it back to enum Type 
and then hope that will work. (it will most likely work if the enum has a large 
enough bit size, but it's technically undefined behaviour, so I can't imagine 
that's how Robert intended it to be used).

To me it seems the feature advertised in docs of creating your own 
StateAttributes simply isn't possible, just because of this one function 
returning enum instead of int, which would be an easy fix. Am I missing 
something here?

Cheers,
Jannik

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65369#65369





___
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] New serialization scheme

[Lionel Lagarde]

Hi,

While writing the post, I realized that I wasn't clear.

I'm trying to do:

REGISTER_OBJECT_WRAPPER(...)
{
ADD_INT_SERIALIZER(Version, -1);
ADD_CONDITIONAL_SERIALIZER(Version, 1, TheDeprecatedProperty);
ADD_CONDITIONAL_SERIALIZER(Version, 2, TheNewProperty);
...
wrapper->addFinishedObjectReadCallback(new UpgradeCallback);
}

The conditional serializer checks the version of the node being read is 
equal
to the version in the macro. If so, it reads property and stores it 
somewhere.


The upgrade callback collects the deprecated properties and build a 
ready to

use node.

Maybe I can get out using the _firstVersion and the _lastVersion members 
of BaseSerializer:


ADD_INT_SERIALIZER(TheMember, -1);
wrapper->_serializers.back()->_firstVersion = N;
wrapper->_serializers.back()->_lastVersion = N;

or using the macros:

UPDATE_TO_VERSION(N);
ADD_INT_SERIALIZER(TheMember, -1);
UPDATE_TO_VERSION(N+1);
REMOVE_SERIALIZER(TheMember);

Using the first/last version members of the serializers, I think I can 
make the serializers

work as I want. I just have to:
- keep the olds interfaces inside the classes
- make sure there is no name collision between the old and the new 
interfaces



Or I stop over-thinking it and create a new class with its own 
serializers when the class changes.
Using a read file callback, I can upgrade the loaded scene graph if it 
contains old nodes.


I think get it.

Thanks.

Lionel Lagarde.


On 23/03/2015 12:33, Robert Osfield wrote:

Hi Lionel,

I'm not clear on what you are looking for, in terms of further 
information, or functionality.


The OSG's SO version is currently used to version the .osgb, .osgt and 
.osgx file formats.  Does this help you?


When implementing your own wrappers it probably best to just look at 
the how similar classes to yours are serialized with the 
src/osgWrappers/serializer/*/*.cpp files.  There are quite a few 
macros that make it easy to wrap basic types, such floats, int, 
strings, etc.  Serialization of UserData is also supported - all you 
need to do is subclass from osg::Object and implement the wrappers.


Robert.


On 23 March 2015 at 09:47, Lionel Lagarde <mailto:lionel.laga...@oktal-se.fr>> wrote:


Hi,

Better late than never, I'm writing the serializers of my own classes
for the osgt, osgb... file formats.

Theses classes exist for a long time, they have evolved a lot.
Both the interfaces
and the implementations have changed.

I try to make a loader that is able to load the files written
using a previous
version of the software. Of course, because the osg{t,b...}
support is new, a new
format will not appear soon but I want to foresee this case.

In the deprecated osg and ive reader writer, because the read and
write procedure were
functions, I was able to read a version number, and according to
it, read the right
parameters and build the class using the right methods.

Because the members of the classes are now loaded independently
from each other, it is now
a little bit more complicated. I'm planning to make my own
serialization
classes (TemplateSerializer, PropByValSerializer...) that are able
to read the
current version number, read the ''thing'' if needed, and store it
somewhere.
Using a FinishedObjectReadCallback, I should be able to build
correctly the classes.

Right now I'm looking for a reading state structure. This
structure has to be
readable/writable by all the serializer classes. Maybe the user
data of the node
is the right place.

Does someone has already faced a similar problem? If so, how you
resolved it?
I don't know well the new serialization scheme, maybe there is a
better solution?

Any clue?

Lionel Lagarde


___
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

[osg-users] New serialization scheme

[Lionel Lagarde]

Hi,

Better late than never, I'm writing the serializers of my own classes
for the osgt, osgb... file formats.

Theses classes exist for a long time, they have evolved a lot. Both the 
interfaces

and the implementations have changed.

I try to make a loader that is able to load the files written using a 
previous
version of the software. Of course, because the osg{t,b...} support is 
new, a new

format will not appear soon but I want to foresee this case.

In the deprecated osg and ive reader writer, because the read and write 
procedure were
functions, I was able to read a version number, and according to it, 
read the right

parameters and build the class using the right methods.

Because the members of the classes are now loaded independently from 
each other, it is now

a little bit more complicated. I'm planning to make my own serialization
classes (TemplateSerializer, PropByValSerializer...) that are able to 
read the
current version number, read the ''thing'' if needed, and store it 
somewhere.
Using a FinishedObjectReadCallback, I should be able to build correctly 
the classes.


Right now I'm looking for a reading state structure. This structure has 
to be
readable/writable by all the serializer classes. Maybe the user data of 
the node

is the right place.

Does someone has already faced a similar problem? If so, how you 
resolved it?
I don't know well the new serialization scheme, maybe there is a better 
solution?


Any clue?

Lionel Lagarde

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node

[Lionel Lagarde]

In order to get the center of the bounding box of a drawable, using to 
Bound helper class, you have to do:

const osg::BoundingBox &bbox = geometry->getBound(); // type cast operator
osg::Vec3 c = bbox.center();

Because:
osg::Vec3 c = geometry->getBound().center();

Will throw a segmentation fault while trying to access to the bounding 
sphere member of the Bound helper class.


User code have to be modified (or at least checked) in order to prevent 
that.


Lionel.

On 14/05/2014 15:04, Robert Osfield wrote:

Hi Lionel,

On 14 May 2014 10:59, Lionel Lagarde  wrote:

The center() method exists in the BoundingBox interface. With the Bound
interface you provide, this code would throw a seg fault:
og::Vec3 c = geometry->getBound().center();


The Bound class that I have implemented so far only access the
BoundingSphere::center() and doesn't attempt to pass back the
BoundingBox::center().  As the BoundingSphere is always implemented
this code should never produce a seg fault.




In order to avoid any modification of user code, the center method (and all
the methods defined in the BoundingBox and the BoundingSphere classes) has
to be redefined in the helper class:
osg::Vec3 Bound::center() const
{
 if (bb) return bb->center();
 return bs->center();
}

But it's a pity to return a new instance of Vec3 for BoundingSphere (it
should be a const reference).


The BoundingBox::center() is really just a convenience method, it
doesn't access a variable in the way that the BoundingSphere::center()
does, so I'm incline not to implement a Bound::center() other than to
access the BoundingSphere::center().

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] Promoting Drawable from being subclassed from osg::Object to osg::Node

[Lionel Lagarde]

The center() method exists in the BoundingBox interface. With the Bound 
interface you provide, this code would throw a seg fault:

og::Vec3 c = geometry->getBound().center();

In order to avoid any modification of user code, the center method (and 
all the methods defined in the BoundingBox and the BoundingSphere 
classes) has to be redefined in the helper class:

osg::Vec3 Bound::center() const
{
if (bb) return bb->center();
return bs->center();
}

But it's a pity to return a new instance of Vec3 for BoundingSphere (it 
should be a const reference).


Lionel.





On 13/05/2014 19:02, Robert Osfield wrote:

I have made a further tweak to my experimental Bound class, adding
center(), radius() from BoundingSphere and xMin(), yMin() etc. methods
from BoundingBox to help make it easier for Bound to act more like a
BoundingSphrere or BoundingBox.

In the code below I provide a segment that deliberately tries to
access BoundingBox methods from a BaseClass object that doesn't have a
BoundingBox so it accesses a NULL and creates a seg fault.  One could
potentially compute xMin() from a BoundingSphere, or we could throw an
exception. I'm not quite sure how much effort to make with this
temporary helper class though as it's only meant as a temporary helper
class to add porting to new versions of the OSG.

Thoughts?
Robert.

Latest Bound implementation:

struct Bound
{
 Bound():
 bb(0),
 bs(0) {}

 Bound(const osg::BoundingSphere& bs):
 bb(0),
 bs(&bs) {}

 Bound(const osg::BoundingBox& bb):
 bb(&bb),
 bs(0) {}

 Bound(const osg::BoundingSphere& bs, const osg::BoundingBox& bb):
 bb(&bb),
 bs(&bs) {}

 const osg::BoundingBox*bb;
 const osg::BoundingSphere* bs;

 const osg::Vec3& center() const { return bs->center(); }
 float radius() const { return bs->radius(); }

 float xMin() const { return bb->xMin(); }
 float yMin() const { return bb->yMin(); }
 float zMin() const { return bb->zMin(); }

 float xMax() const { return bb->xMax(); }
 float yMax() const { return bb->yMax(); }
 float zMax() const { return bb->zMax(); }

 operator const osg::BoundingBox& () const { return *bb; }
 operator const osg::BoundingSphere& () const { return *bs; }
};

struct BaseClass
{
 osg::BoundingSphere _bs;
 virtual Bound getBound() const { return Bound(_bs); }
};

struct SubClass : public BaseClass
{
 osg::BoundingBox _bb;
 virtual Bound getBound() const { return Bound(_bs, _bb); }
};


int main(int, char**)
{

 BaseClass object1;
 SubClass object2;

 const osg::BoundingSphere& bs1 = object1.getBound();
 const osg::BoundingBox& bb1 = object1.getBound();

 OSG_NOTICE<<"bs1 = "<<& bs1

Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node

[Lionel Lagarde]

Hi,

Wonderful. Our code is full of:
  if the object is a drawable then
do something for the drawable
  else
do something for the node

For the getBound problem, I think there is no solution. The return type
is not included in the function prototype.

Lionel.


On 13/05/2014 17:13, Robert Osfield wrote:

Hi All,

Over the last day I have been experimenting with changing
osg::Drawable so that it is subclassed from osg::Node rather than
osg::Object.  The motivation behind this change is to make it simpler
to build scene graphs that only contain a single geometry and enabling
one to just directly attach a Geometry to the scene graph, without the
need for decorating it with a Geode first.

I have got the OSG build and running fine with this change, but I had
to make more changes to code that accessed Drawable than I'd have
liked, and this concerns me about the impact it may have on end users
that will be forced to update their code toI  ideally I'd get things
to a point where very few users need to do anything more than a
recompile against the new version of the OSG.  With this goal in mind
I'd like feedback from the community about what solutions

The problem area is the overlap between the Node::getBound() that
returns a BoundingSphere and the Drawable::getBound() that returns a
BoundingBox.  Any code that gets the bounding box from the Drawable
using the getBound() method will now fail to compile as it'll be
getting a BoundingSphere back in place.  My current workaround to this
is to have a Drawable::getBoundingBox() method that the can be used to
directly access the Drawable's BoundingBox.   This tweak is perfectly
valid implementation but it does require calling code to be modified.

Might there be alternatives that C++ can help us with?  In a perfect
world we'd be able to select the appropriate getBound() implementation
depending upon what type it's being assigned to ie.:

 // get the bounding sphere of the Drawable
 const BoundingSphere& bs = drawable->getBound();

 // but we also want the old code to keep compiling where we want
the bounding box
 const BoundingBox& bb = drawable->getBound();

I'm currently trying to think of ways to solve this conundrum.  There
might be a simple C++ trick that I've overlooked, which is why having
a nice big community of C++ programmers is an asset :-)

So what's solutions can you think of?

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] Curious compiler behavior

[Lionel Lagarde]

Hi Nick,

The solution involving the #ifdefs is to use the osgDB::fstream classes 
instead of the std ones using #defines:


#ifdef WIN32

// Replace STL fstream with OSG fstream
#include 
#define ifstream osgDB::ifstream
#define ofstream osgDB::ofstream

#else

#include 
#define ifstream std::ifstream
#define ofstream std::ofstream

#endif

It doesn't apply in my case.

But I manage to make the it works using directly the vector 
implementation of the MixinVector:

osg::IntArray *array = ...
std::vector &v = array->asVector();
v[0] = 10;




On 13/12/2013 11:50, Trajce Nikolov NICK wrote:

Hi Lionel,

this topic was discussed before as I can recall and there was a neat 
solution (with #ifdefs) posted to avoid the conflict. Have a look in 
the archive, can not remember the author


Nick


On Fri, Dec 13, 2013 at 1:41 PM, Lionel Lagarde 
mailto:lionel.laga...@oktal-se.fr>> wrote:


My problem looks like the osgDB::fstream / std::fstream conflict
which was resolved using the /FORCE:MULTIPLE linker flag.
Does anyone has more information on this ?


On 12/12/2013 18:39, Lionel Lagarde wrote:

It seems that osg80-osgd.dll contains the symbols of "scalar
integer" (char, uchar, short, ushort, int, uint)
specializations of the
MixinVector.

The vector and floating point specializations are not defined.

    On 12/12/2013 18:19, Lionel Lagarde wrote:

Hi,

I use Visual Express C++ 2010.

The following code works very well:
osg::FloatArray *array = ...
(*array)[i] = 10.0;

I decided to add integer support:
osg::IntArray *array = ...
(*array)[i] = 10;

And the linker says:
osgd.lib(osg80-osgd.dll) : error LNK2005: "public: int &
__cdecl osg::MixinVector::operator[](unsigned __int64)"
already defined in libseFastOsgCored.lib(OsgUniform.obj)

Any idea ?

___
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
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




--
trajce nikolov nick


___
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] Curious compiler behavior

[Lionel Lagarde]

My problem looks like the osgDB::fstream / std::fstream conflict which 
was resolved using the /FORCE:MULTIPLE linker flag.

Does anyone has more information on this ?

On 12/12/2013 18:39, Lionel Lagarde wrote:
It seems that osg80-osgd.dll contains the symbols of "scalar integer" 
(char, uchar, short, ushort, int, uint) specializations of the

MixinVector.

The vector and floating point specializations are not defined.

On 12/12/2013 18:19, Lionel Lagarde wrote:

Hi,

I use Visual Express C++ 2010.

The following code works very well:
osg::FloatArray *array = ...
(*array)[i] = 10.0;

I decided to add integer support:
osg::IntArray *array = ...
(*array)[i] = 10;

And the linker says:
osgd.lib(osg80-osgd.dll) : error LNK2005: "public: int & __cdecl 
osg::MixinVector::operator[](unsigned __int64)" already defined in 
libseFastOsgCored.lib(OsgUniform.obj)


Any idea ?

___
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] Curious compiler behavior

[Lionel Lagarde]

It seems that osg80-osgd.dll contains the symbols of "scalar integer" 
(char, uchar, short, ushort, int, uint) specializations of the

MixinVector.

The vector and floating point specializations are not defined.

On 12/12/2013 18:19, Lionel Lagarde wrote:

Hi,

I use Visual Express C++ 2010.

The following code works very well:
osg::FloatArray *array = ...
(*array)[i] = 10.0;

I decided to add integer support:
osg::IntArray *array = ...
(*array)[i] = 10;

And the linker says:
osgd.lib(osg80-osgd.dll) : error LNK2005: "public: int & __cdecl 
osg::MixinVector::operator[](unsigned __int64)" already defined in 
libseFastOsgCored.lib(OsgUniform.obj)


Any idea ?

___
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] Curious compiler behavior

[Lionel Lagarde]

Hi,

I use Visual Express C++ 2010.

The following code works very well:
osg::FloatArray *array = ...
(*array)[i] = 10.0;

I decided to add integer support:
osg::IntArray *array = ...
(*array)[i] = 10;

And the linker says:
osgd.lib(osg80-osgd.dll) : error LNK2005: "public: int & __cdecl 
osg::MixinVector::operator[](unsigned __int64)" already defined in 
libseFastOsgCored.lib(OsgUniform.obj)


Any idea ?

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Preferred method for per-context uniforms

[Lionel Lagarde]

Hi,

We have to manage some similar problems. We have different shaders and 
different uniforms in the same

scene graph.

Some nodes have a cull callback. During the cull traversal, the callback 
identify the current view/context
and push the corresponding state set in the render graph, traverse the 
children and pop the state set.




On 23/10/2013 18:49, Robert Osfield wrote:

HI Paul,

If you have just a single uniform value per context then I'd simply 
place the Uniform on the each if the viiewer's osg::Camera's StateSet, 
such that each Camera assigned to each Context gets it's own state 
inherited down including the Uniform.


If you want to put a vector of Uniform in the scene graph, then It 
would probably be most robust to use a custom osg::Group node that 
manages the cull traversal where it push/pops the approach Unifiorm as 
well as any resizeGLObjectBuffers/releaseGLObjects etc.  The key to 
doing it thread safe is to make sure you have allocated the vector to 
the required number of contexts prior to traversal - this is what the 
resizeGLObjectsBuffers() helps with.


Robert.


On 23 October 2013 17:38, Paul Martz > wrote:


Hi all -- I've been inactive with OSG lately, but from time to
time get called back. Given my lack of recent experience, I would
appreciate your help with this issue.

I have a multicontext/multidisplay app that needs to compute a
uniform during cull, and it will have a different value for each
context/display. Computing the uniform value is straightforward,
but actually executing the uniform per-context during draw is
somewhat difficult.

I can't simply store the uniform in the Node's StateSet, for
example, because doing that during cull is not thread safe.

Ideally I would store the uniform in a vector indexed by context
ID, but I don't have a context ID during cull.

Would it be feasible to store the uniforms in a map indexed by
RenderStage address, then execute the uniforms from a Camera
per-draw callback?

Assuming I use a per-context or per-RenderStage container to store
the uniforms, how do I initially grow that container in a
thread-safe way during the first frame?

What are other people doing in this situation? Thanks in advance
for the advice.

-- 
Paul Martz

Skew Matrix Software LLC

___
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] questions about lightning(thunder)

[Lionel Lagarde]

Hi,

I use textured axial billboard starting from the cloud layer to the 
ground to render lightnings.

A short-lived light source is used to illuminate the surrounding objects.
The light source use quadratic attenuation.

On 05/06/2013 08:17, Kim JongBum wrote:

Hi, guys

is there some way to render thunder?

i think that i could use the thunder image but

what i wanna know is how to render the flashing or lightning with images?

i mean how to flicker(blink) the light of thunder at specified area(part of 
area)

Thanks in advance

Cheers,
Kim

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54460#54460





___
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] Any recent work on CIGI interfaces to OSG?

[Lionel Lagarde]

Hi,

I work on an image generator based on OpenSceneGraph and driven by CIGI 
commands.


Web site of the company: http://www.oktal-se.fr
Section SE-FAST-IG.

At first MPV was a source of inspiration. This is no longer the case 
now. It's been a few years since I look at MPV base code.


Lionel


On 24/05/2013 23:26, Chris Calef wrote:

Hi,

I'm new to OSG, coming in from the direction of FlightGear, but I'm 
here primarily because I am interested in implementing a CIGI 
interface to FlightGear, and would like to put as much of this work as 
possible into an OSG module in order to make it useful to the larger 
OSG community and not only FlightGear developers.


I have read the conversations about doing this from several years ago, 
but have not found any recent discussion or located any available code 
drops.  I have downloaded the MPV example from CIGI at sourceforge, 
which is based on OSG, and that is quite helpful, but I wanted to 
introduce myself here and see if anyone can catch me up on any other 
existing work in this direction, or give me advice about where to start.


Much of the CIGI interface is dedicated to higher order simulation 
functions (ie celestial bodies, ocean conditions, aircraft controls) 
which are probably too specific to implement at the OSG layer, but I'd 
like to make at least a virtual wrapper in OSG which could be 
inherited by FlightGear and other OSG based projects, each of which 
could determine on its own which functions to support, and how to 
support them.


Any pointers would be welcome.  I am applying for funding for this 
project in one week, so the more information I can gather before then 
the better.


Thanks for all your efforts!

Chris Calef, CTO
BrokeAss Games, LLC



___
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] crashing with paged LODs, line intersector on computeBound

[Lionel Lagarde]

Hi,

Maybe your picking threads traverse the scene graph while the database 
pager or the incremental compile operation modify it.


During the update traversal of the viewer, the no longer visible terrain 
tiles are removed from the scene graph and the just loaded tiles are 
merged with the scene graph.
If an intersection visitor traverse a part of the scene graph while the 
paging processadds or removes a child, the application will most 
probably crash.


The solution I used is to break up the Viewer::run method and call the 
event, update, rendering traversalsmanually:


eventTraversal()
stop the picking threads
updateTraversal()
restart the picking threads
renderingTraversal()

The ViewerBase::updateTraversalmethod is virtual. Another solution is to 
sub-class the Viewerand overload the update traversal:


::updateTraversal
{
stop the picking threads
Viewer::updateTraversal()
restart the picking threads
}

On 15/05/2013 23:08, Joe Doob wrote:

Hi,

I wonder if anyone can offer some insight on why I may be experiencing these 
random crashes.

Essentially I have many line intersection visitors following a node which is 
moving through the scene and performing line intersections on terrain, which is 
a pagedLOD database of proxynodes.

This is done in a multithreaded fashion, i.e. there are many threads each with 
a lineSegmentIntersector and intersectionVisitor of its own. By and large, it 
works great, but on very rare and seemingly random occasions the application 
crashes with a segmentation fault.

It traces to the accept call, where I am calling the terrain's group node's 
accept function on an intersection visitor.

A human-friendly version of the backtrace is as follows:
  


Code:

osg::Group::computeBound at Group.cpp
  osg::LOD::computeBound at LOD.cpp
getBound at Node.cpp
isCullingActive at Node.cpp
enter at LineSegmentIntersector.cpp
enter at IntersectionVisitor.cpp
accept at Group.cpp
traverse at Group.cpp
apply at IntersectionVisitor.cpp
accept at Group.cpp




The code that performs the actual intersection looks like this:


Code:

lineSegmentIntersector->setStart(start);
lineSegmentIntersector->setEnd(end);
intersectionVisitor->reset();
root->accept(*intersectionVisitor);




It's possible I am doing something evil with this multithreading setup that I 
am unaware of (please tell me!), but since everything works 99.9% of the time, 
I suspect there is something more subtle going on.

I am running OSG 3.0.1 in C++.

Thanks,
Stathibus

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54021#54021





___
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] [osg-submissions] Texture compilation using PixelBufferObject

[Lionel Lagarde]

Hi Robert,

Yes. "copy data and release GL buffer object" mechanism cannot be used 
as it is. Unfortunately (fortunately), I'm in holidays for 3 weeks. I 
can make the related corrections but I will not be able to test them.


I'll be back the 7 jan. Hope the world doesn't end during my holidays ...

By

Lionel

On 14/12/2012 15:07, Robert Osfield wrote:

HI Lionel,

On 14 December 2012 10:48, Lionel Lagarde <mailto:lionel.laga...@oktal-se.fr>> wrote:


Hi Robert,

osg::Image inherits from osg::BufferData. The BufferData cannot be
unreferenced separately.


Indeed, I knew this but didn't make the connection! :-)

The behavior you describe is the what happen if "unref image data
after apply" is true and "copy data and release GL buffer object"
is false (like in my submission).


Yes.  I'm starting to think the BufferData level "copy data and 
release GL buffer object" is misguided and broken in it's current form 
and might be better off just removing it completely or doing a proper 
rethink and refactor of the support for this feature.


Multi-context doesn't work if "unref image data after apply" is
true because the image is referenced only once by the texture and
not one per context.


There is support in osg::Texture for making sure all the contexts have 
applied the image before the image gets unref'd.


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] [osg-submissions] Texture compilation using PixelBufferObject

[Lionel Lagarde]

Hi Robert,

osg::Image inherits from osg::BufferData. The BufferData cannot be 
unreferenced separately.


The behavior you describe is the what happen if "unref image data after 
apply" is true and "copy data and release GL buffer object" is false 
(like in my submission).


Multi-context doesn't work if "unref image data after apply" is true 
because the image is referenced only once by the texture and not one per 
context.




On 14/12/2012 11:20, Robert Osfield wrote:

Hi Lionel,

On 14 December 2012 10:07, Lionel Lagarde <mailto:lionel.laga...@oktal-se.fr>> wrote:


Hi Robert,

Proposal:

new member: BufferData::_numUsers initialized to
BufferData::getReferenceCount when the GL buffer object is created
and filled

In Texture:apply, decrement the _numUsers member of the Image and
release the GL buffer object if the sum of the _numUsers of all
the BufferData contained if the GL buffer object is 0

Any thoughts ?


Doesn't feel elegant to me.

I wonder if we could unref the BufferData by removing it form the 
osg::Image and let it's ref count control it's destruction, and when 
it destructs it'll destruct the PixelBufferObject if it no longer has 
any references.


This would be a bit similar to the way that the osg::Image is 
unref'd.  Like this mechanism we'd need to make sure that the 
BufferData is applied to all the contexts that require it.


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] [osg-submissions] Texture compilation using PixelBufferObject

[Lionel Lagarde]

Hi Robert,

Proposal:

new member: BufferData::_numUsers initialized to 
BufferData::getReferenceCount when the GL buffer object is created and 
filled


In Texture:apply, decrement the _numUsers member of the Image and 
release the GL buffer object if the sum of the _numUsers of all the 
BufferData contained if the GL buffer object is 0


Any thoughts ?

Lionel

On 14/12/2012 10:12, Robert Osfield wrote:

Hi Lionel,

Thanks for the explanation/code segment on the other thread.  I now 
understand what is at issue, when an PBO is shared between 
osg::Texture/osg::Image the release is done by the first texture that 
applies it, rather than the last one to need it.  I don't think the 
suggested fix of modifying the IncrementalCompileOperation is 
appropriate - it just hides the bug which is actually in the way that 
osg::Texture does the release based on the assumption that it's the 
only one using it.  A proper solution will be to add some support into 
osg::BufferObject for registering when BufferData has been used and no 
longer required.


Robert.


___
osg-submissions mailing list
osg-submissi...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture compilation using PixelBufferObject

[Lionel Lagarde]

Hi Robert,

You're right. The reference counter of the buffer object is exactly what 
I want. In order to be able to release the GL buffer after the last 
texture compilation, the boolean "copy data and release GL buffer 
object" of the buffer object should also be set to false in StateToCompile.


Trying ...

On 13/12/2012 15:43, Robert Osfield wrote:

HI Lionel,

Might the Texture::setUnRefImageDataAfterApply() mechanism be useful 
here?  As the osg::Image is released then the BufferObject would be 
decremented till eventual it itself is deleted.  In theory I'd expect 
this to happen right now.  Is there an issue here?


Robert.

On 12 December 2012 14:32, Lionel Lagarde <mailto:lionel.laga...@oktal-se.fr>> wrote:


Hi,

Let's imagine this scenario:

The database pager loads the file "x.osgb".
This file contains 3 geometries (A, B, C). A has a texture
that uses A.jpg, B uses B.jpg and C uses C.jpg. These textures
are not used by the already rendered geometry (i.e. not compiled)
The FindCompileableGLObjectsVisitor is configured to set a
pixel buffer object on the texture's image. An unique buffer
object (shared by the 3 images) is created.
The buffer object is configured to release it's GL buffer once
the texture is applied
(setCopyDataAndReleaseGLBufferObject(true)).
After the draw dispatch, the IncrementalCompileOperation
compiles the new geometries and textures:

for each textures

texture->apply(. . .) =

bind the buffer object
copy A.jpg, b.jpg and C.jpg in the buffer (the 3
images are copied because the buffer object is shared)

glTex[Sub]Image(. . ., offset of the current image
in the buffer)

if (getCopyDataAndReleaseGLBufferObject())

release GL buffer

So, for each texture, a GL buffer is created, the 3 images are
copied, the data is copied in the texture using the current
image offset in the buffer and the buffer is deleted.

The GL buffer should not be released before all the images are
copied into their textures(i.e. glTex[Sub]Image for all the textures).

There are few usages cases of a pixel buffer object:

  * texture paging (IncrementalCompileOperation): the GL buffer
release can be done after the compilation loop
  * rendering (a noncompiled texture is used to render geometry):
the GL buffer release can be done once all the textures using
the buffer are compiled
  * texture streaming (movie): the GL buffer should not be released

The first 2 cases can be handledusing some king of reference
counter (the buffer contains X segments, each glTex[Sub]Image
decrements this counter, when it reaches 0the buffer can be released).

In the third case, the buffer should never be released. The
counter should not be decremented.

What do you think about this? I'm not sure all the usage cases are
covered, especially if the buffer is a vertex buffer or an indices
buffer.

Lionel Lagarde


___
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

[osg-users] Texture compilation using PixelBufferObject

[Lionel Lagarde]

Hi,

Let's imagine this scenario:

   The database pager loads the file "x.osgb".
   This file contains 3 geometries (A, B, C). A has a texture that uses
   A.jpg, B uses B.jpg and C uses C.jpg. These textures are not used by
   the already rendered geometry (i.e. not compiled)
   The FindCompileableGLObjectsVisitor is configured to set a pixel
   buffer object on the texture's image. An unique buffer object
   (shared by the 3 images) is created.
   The buffer object is configured to release it's GL buffer once the
   texture is applied (setCopyDataAndReleaseGLBufferObject(true)).
   After the draw dispatch, the IncrementalCompileOperation compiles
   the new geometries and textures:

   for each textures

   texture->apply(. . .) =

   bind the buffer object
   copy A.jpg, b.jpg and C.jpg in the buffer (the 3 images
   are copied because the buffer object is shared)

   glTex[Sub]Image(. . ., offset of the current image in
   the buffer)

   if (getCopyDataAndReleaseGLBufferObject())

   release GL buffer

   So, for each texture, a GL buffer is created, the 3 images are
   copied, the data is copied in the texture using the current image
   offset in the buffer and the buffer is deleted.

The GL buffer should not be released before all the images are copied 
into their textures(i.e. glTex[Sub]Image for all the textures).


There are few usages cases of a pixel buffer object:

 * texture paging (IncrementalCompileOperation): the GL buffer release
   can be done after the compilation loop
 * rendering (a noncompiled texture is used to render geometry): the GL
   buffer release can be done once all the textures using the buffer
   are compiled
 * texture streaming (movie): the GL buffer should not be released

The first 2 cases can be handledusing some king of reference counter 
(the buffer contains X segments, each glTex[Sub]Image decrements this 
counter, when it reaches 0the buffer can be released).


In the third case, the buffer should never be released. The counter 
should not be decremented.


What do you think about this? I'm not sure all the usage cases are 
covered, especially if the buffer is a vertex buffer or an indices buffer.


Lionel Lagarde

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] kd tree ray tracing performance

[Lionel Lagarde]

O_o

The tables look messy.

reposting

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=50502#50502





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] kd tree ray tracing performance

[Lionel Lagarde]

Hi,

Here are some bench I have made few years ago (2008).

Tests description:
- scene 1: 200x200 grid (8 triangles, 40401 vertices), only one geometry
- scene 2: small part of a real terrain (16x16 km), 1600+ geometries, 
quad tree shaped scene graph


The benchmark application display the scene and 30 mobile objects (on a 
trajectory) clamped on the ground.


Clamping time:

Scene



w/o Kd-Tree



w/ Kd-Tree

Min (ms)



Max (ms)



Avg (ms)



Min (ms)



Max (ms)



Avg (ms)

1



2,890



3,280



3,105



0,021



0,029



0,023

2



0,270



1,185



0,625



0,079



0,410



0,242


Here is the same tests with the code of LineSegmentIntersector doing the 
segment/triangle intersection test commented out (== scene graph 
traversal time):


Scene



scene graph traversal time

Min (ms)



Max (ms)



Avg (ms)

1



0,003



0,005



0,003

2



0,057



0,385



0,227

So the traversal of the leaves are:




w/o Kd-Tree



w/ Kd-Tree

1



3,105 -- 0,003 = 3,102



0,023 -- 0,003 = 0,020

2



0,625 -- 0,227 = 0,398



0,242 -- 0,227 = 0,015

Here are the gain of using Kd-Trees:




Global



Only leaves

scene 1



-99,26%



-99,36%

scene 2



-61,28%



-96,23%

And the memory cost:




Number of Kd-trees



Total Kd-Tree size

scene 1



62



4,65 MB

scene 2



1



38,06 MB


On 08/10/2012 11:26, Robert Osfield wrote:

H Tolga,


On 8 October 2012 08:09, Tolga Yilmaz  wrote:

is there any example that compares ray tracing performance in ms between kdtree 
and normal implementation with osg? i remember some time i found such an 
example and modified it, but couldnt find that code now.

There isn't any example that address this right now.  You could
modified the osginterstion example to add a command line option for
enabling the build of kdtree's and then use it as a benchmarking tool.

When developing the KdTree support I did plenty of benchmarking but I
never truned these tests into a OSG example and don't have the code
anymore unfortunately - I do lots of prototype/testing so don't tend
to keep all the tests around.   From my experience KdTree's help most
when the scene graph is composed of large osg::Geometry meshes - here
it can be 10 to 1000's of times faster, if the scene graph is already
very fine grained with many small osg::Geometry meshes then the
difference is much smaller.

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] Warning: Manipulator warning: eventTimeDelta = -0.004

[Lionel Lagarde]

  
  
Hi, 

When I use the FlightManipulator, I have a lot of warning messages:
"Manipulator warning: eventTimeDelta = -0.004".
The messages are displayed only using ON_DEMAND rendering.

The GraphicsWindow has an event queue. The window related event
(mouse move, ...) are appended in this queue.

The osgViewer::View has also an event queue (not shared with the
window). A FRAME event is pushed in this queue in the advance
method.

A frame is made of:
    advance
    {
        push FRAME event time = reference time = delta_s(view start
tick, now)
    }

    eventTraversal
    {
        gw->checkEvents => fill the GraphicsWindow event queue
time = delta_s(event queue start tick, now) > FRAME event time
        append gw events to a local event queue
        append view events to the local event queue

        here, the local event queue contains:
            gw event (time = T)
            gw event (time = T+1)
            gw event (time = T+2)
            ...
            FRAME event (time = T-1)

        the local event queue is not sorted (by event time) and the
FlightManipulator doesn't like it.
    }

The warnings are not printed in the CONTINUOUS rendering mode
because the takeEvents method (used to takes the events from the
graphics window event queue and the view event queue) uses a cutoff
time (reference time). The window events are processed by the
manipulator during the frame N+1.

These messages are quite annoying. They exist in OSG 2.x but they
are notified as info (most of the time not printed).

I don't know how to correct this issue:

  sort the local event queue (using the event times) before the
event dispatch
  always set cutoff time = reference time
  make the manipulators more flexible 
  
  ...

Any ideas ?
  

  

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mail2Forum

[Lionel Lagarde]

Hi,

I have a problem with the mail list. I use thunderbird to read/write the posts. 
I don't use the forum. 

I posted a reply to the question about setCenterByMousePointerIntersection by 
Joe Kilner. I received (in thunderbird) the corresponding mail. 
But in the forum, I can't see my reply.

Actually, sometime a mail comes into my mailbox with the subject beginning by 
"Re: " and I can't find the source mail.
For example, I received this morning the mail from Torben Dannhauer (zonk in 
the forum) "Re:  [ANN] New version of 3rdParty Package" and I didn't received 
the source message.

The web site is currently down. I will unsubscribe/subscribe to the mail lists 
as soon as possible.

Thank you!

Cheers,
Lionel

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41331#41331





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] setCenterByMousePointerIntersection

[Lionel Lagarde]

  
  
Hi, 
  
  In our application, I do (when a "center-on" event is sent) :
  osgGA::MatrixManipulator *mm = viewer->getCameraManipulator();
  mm->setHomePosition(eye, center, up);
osg::ref_ptr
  ea = new osgGA::GUIEventAdapter;
mm->home(*ea, *viewer);

On 08/07/2011 18:31, Joe Kilner wrote:

  Hi,

I am often loading large scenes in to a Viewer with a TrackballManipulator and would really like a nice way to reset the orbit point while viewing the model. 

I had a look in the code and found something looking like what I want has been implemented already and can be activated by passing the flag SET_CENTER_ON_WHEEL_FORWARD_MOVEMENT when creating the manipulator.

However, I can't get it to work and am not really sure how (or even if) the feature should be used. Can anyone shed any light?

Thank you!

Joe

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41275#41275





___
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] saved_animation.path

[Lionel Lagarde]

Sorry, I forgot the time (first)

Lionel Lagarde wrote:

  
  
  x y z (camera's position) + x y z w (camera's orientation
quaternion)
  
sunitha sunagad wrote:
  


-- Can anyone tell me what are the values that are getting recorded in
saved_animation.path file after recording
I can see 8 values please let me know what are they...









Regards
Sunitha.S.Sunagad 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



__ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 3855 (20090216) __

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

  
  
  
  
__ Information provenant d'ESET NOD32 Antivirus, version de la
base des signatures de virus 3855 (20090216) __
  
Le message a été vérifié par ESET NOD32 Antivirus.
  
  http://www.eset.com
  

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



__ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 3855 (20090216) __

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

  



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] saved_animation.path

[Lionel Lagarde]

x y z (camera's position) + x y z w (camera's orientation
quaternion)

sunitha sunagad wrote:

  
  
-- Can anyone tell me what are the values that are getting recorded in
saved_animation.path file after recording
  I can see 8 values please let me know what are they...
  
  
  
  
  
  
  
  
  
Regards
Sunitha.S.Sunagad 
  

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



__ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 3855 (20090216) __

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

  



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Problem in FluidFrictionOperator

[Lionel Lagarde]

Hi Robert,

the attached file show the problem.

With the SVN version the particles get weird speed.

With the revised version of FluidFrictionOperator.cpp, the
problem disappear.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Delete order in osgViewer::Viewer

[Lionel Lagarde]

...

The application which plants is based on 2.6 but I thought (apparently
not) 
of having verified SVN sources.

Rechecking ...

Robert Osfield wrote:

  Hi Lionel,

I believe this issue is now fixed.  Which version of the OSG are you using?

Robert.

On Tue, Jan 20, 2009 at 8:45 AM, Lionel Lagarde
 wrote:
  
  
Hi,

We have a scenario editor that is able to create and destroy
osgViewer::Viewer.
When a Viewer is deleted, its graphic context is closed. All the GL objects
used in this context are deleted.

The osg::View destructor is called after the Viewer destructor (because
osgViewer::Viewer inherits from osg::View). The View deletes its camera.

The osg::Camera holds a GraphicsOperation (osgViewer::Renderer) which
is deleted here. The renderer destructor unref its osgUtil::SceneView(s).

The sceneview owns an osgUtil::StateGraph which is deleted here.

ouch...

When the state graph is deleted (and if OSG has been compiled with
OSGUTIL_RENDERBACKEND_USE_REF_PTR), the state sets and the drawables
collected in the last culling traversal are deleted. The textures
of the state sets are deleted. And they register their GL object name
to be reused. :'(


So, when a new viewer is created with the same context ID (now available),
and the textures of the new scene request a new GL object, OSG try to reuse
a deleted texture object.

In my case, the application crash because :
- a texture is created (the texture object hasn't been reused because
 the match function as failed for all the "to be reused texture objects".
 The GL id of this texture is X. But there is a "to be reused texture
 object" that has an id of X.
- another texture is created. This texture reuse texture object X.
- a texture created to store a depth component (first texture) is used
 to upload RGBA data. :'(   ... crash.

For the moment, I call osg::discardAllDeletedGLObjects(contextID) just
after the viewer destruction. It works.

I'm searching a place in osg or in osgViewer to insert the GL object
discard.

Maybe the best is in GraphicsContext::close (discard if the context
is not shared).

Suggestion ?


___
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

__ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 3780 (20090120) __

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com




  



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Delete order in osgViewer::Viewer

[Lionel Lagarde]

Hi,

We have a scenario editor that is able to create and destroy 
osgViewer::Viewer.

When a Viewer is deleted, its graphic context is closed. All the GL objects
used in this context are deleted.

The osg::View destructor is called after the Viewer destructor (because
osgViewer::Viewer inherits from osg::View). The View deletes its camera.

The osg::Camera holds a GraphicsOperation (osgViewer::Renderer) which
is deleted here. The renderer destructor unref its osgUtil::SceneView(s).

The sceneview owns an osgUtil::StateGraph which is deleted here.

ouch...

When the state graph is deleted (and if OSG has been compiled with
OSGUTIL_RENDERBACKEND_USE_REF_PTR), the state sets and the drawables
collected in the last culling traversal are deleted. The textures
of the state sets are deleted. And they register their GL object name
to be reused. :'(


So, when a new viewer is created with the same context ID (now available),
and the textures of the new scene request a new GL object, OSG try to reuse
a deleted texture object.

In my case, the application crash because :
- a texture is created (the texture object hasn't been reused because
 the match function as failed for all the "to be reused texture objects".
 The GL id of this texture is X. But there is a "to be reused texture
 object" that has an id of X.
- another texture is created. This texture reuse texture object X.
- a texture created to store a depth component (first texture) is used
 to upload RGBA data. :'(   ... crash.

For the moment, I call osg::discardAllDeletedGLObjects(contextID) just
after the viewer destruction. It works.

I'm searching a place in osg or in osgViewer to insert the GL object
discard.

Maybe the best is in GraphicsContext::close (discard if the context
is not shared).

Suggestion ?


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Question about FluidFrictionOperator

[Lionel Lagarde]

Hello,

I think that I found a problem on 
osgParticle::FluidFrictionOperator::operate(Particle* P, double dt),

I suppose that the current modular program is in relative reference frame.

The method compute a force (Fr) from velocity of the particle which is 
in local space


The force is then converted in world space

 if (_current_program->getReferenceFrame() == 
ModularProgram::RELATIVE_RF) {

 Fr = _current_program->rotateLocalToWorld(Fr);
 }

Then delta velocity computed in world space is added to the particle 
velocity which is on local space


  // correct unwanted velocity increments
  osg::Vec3 dv = Fr * P->getMassInv() * dt;
  float dvl = dv.length();
  if (dvl > vm) {
  dv *= vm / dvl;
  }

  P->addVelocity(dv);

I think that there is a problem.

Can someone tell me if I wrong or not?

Thank you.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] msvc90 dependencies

[Lionel Lagarde]

Hi,

C++ object/static library/dynamic library are not compatible across
compilers because the standard does not define a mangling format.

The C standard defines the way to name the variables and the functions in
object files. C++ doesn't. So there is one mangling format per compiler.

Gordon Tomlinson wrote:

Mattias You can edit the wiki page ..   :)

Search the wiki site for the password its on there




__

Capture the magic of Christmas this year see http://www.capturethemagic.com

__
Gordon Tomlinson 


[EMAIL PROTECTED]
IM: [EMAIL PROTECTED]
www.vis-sim.com www.gordontomlinson.com 


__


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mattias
Helsing
Sent: Monday, December 01, 2008 7:34 PM
To: OpenSceneGraph Users
Subject: [osg-users] msvc90 dependencies

Hi all,

I have seen in recent posts that people aren't aware of my set of
prebuilt binaries for vc90. It is here:

http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHels
ing

It has been there since early sept.

A few people have requested that it be linked to from the win32
dependencies wiki page but I have refrained from poking Robert about
this since I know that Mike has a plan for msvc90. Until then the link
may be a good idea.

cheers
Mattias
___
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] DatabasePager question ...

[Lionel Lagarde]

Hi, 

the osgDB::DatabasePager discards a database request if its frameNumber
is earlier
than the current frameNumber. Your requestNodeFile method has to
continuously
call osgDB::requestNodeFile even if the tile has already been requested.


Adrian Egli OpenSceneGraph (3D) wrote:
Hi all , 
  
One of our application is working with a derrived class of database
pager. Our class has just over written 
::requestNodeFile(const std::string& inFileName,osg::Group* group,
float priority, const osg::FrameStamp*
framestamp,osg::ref_ptr &databaseRequest) 
method. There we get a request form osgDB core (osgUtil::cull visitor)
and we generate a event to generate the right tile from a database. the
event gets handled in a second thread, once he has finish 
generating the right tile, we insert the information into a list. once
a requested tile is in a liste we can make use of the common database
pager 
requestnodefile method. so we just call
DatabasePager::requestNodeFile(inFileName,group,priority,framestamp,databaseRequest);
so it seams to work, but unfortunatelly there are 
in some cases missing requestnodefile calls, means the database pager
should still have such missing tiles, but i don't get right informed,
or the database pager doesn't page in the tiles, may there is
something wrong with the framestamp. or is there something implement to
give a maximum of time to page in a tile. ? after such a time slot
there will no longer paged in the requested tile. ? 
  
adrian 
  
-- 

Adrian Egli
  

___
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] Loose texture in ive after display the node

[Lionel Lagarde]

Hi, 

the texture used in your model has the unRefImageDataAfterApply flag
set. The apply occurs
in the first frame. You can turn off this flag in the Texture attribute.

Eric ZAREMBA wrote:

  
  
  
  
  Hi,
   
  I have a
strange problem during .IVE saving.
  As you can
see in the following, I just open an .IVE
file, display it and save it.
  After this
tree operation, the new .IVE file has
loosing his texture…
  I have the
problem with the file join to the email
(and a lot of others…).
  But I have
some other .IVE files which work correctly
without any problem…
  I suppose
that the error comes from the .IVE file structure?
Can you help me?
   
  During my
test, I had a file which was saved
properly. But, if it was included via a ProxyNode, it was embedded into
the
root ive and lost its textures.
   
  Context:
  Windows XP
SP3
  NVidia
7600GT or ATI FireGL 5100V
  OSG 2.6
  Visual
Studio 2005 SP1
  Qt 4.3 even
if it is not used in the example below.
   
  #include 
  #include 
  #include 
  #include 
   
  int
main(int
argc, char
*argv[])
  {
   
osg::ArgumentParser
args( &argc, argv );
   
osgViewer::Viewer
viewer( args );
   
viewer.realize();
   
   
osg::ref_ptr
pNode = osgDB::readNodeFile( "Data/BufferStop.ive"
);
   
  if(
!pNode )
     
osg::notify(
osg::ALWAYS ) << "Cannot
read the file\n";
   
   
  viewer.setSceneData(
pNode.get() );
    viewer.setCameraManipulator(
  new
osgGA::TrackballManipulator );
   
   
  // If we write the
node before show it,
the result is Ok.
   
  if(
!osgDB::writeNodeFile(
*pNode, "../HopBefore.ive"
) )
   
{
     
osg::notify(
osg::ALWAYS ) << "Failed\n";
     
  return 1;
   
}
   
   
  while(
!viewer.done() )
     
viewer.frame();
   
   
  // Since we displayed
the node, we loose
the texture at saving.
   
  if(
!osgDB::writeNodeFile(
*pNode, "../HopAfter.ive"
) )
   
{
     
osg::notify(
osg::ALWAYS ) << "Failed\n";
     
  return 1;
    }
   
    return 0;
  }
   
  Best
regards,
  Eric Z.
   
   
  
  

___
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] RenderBin understanding

[Lionel Lagarde]

Hi Peter,

Peter Wraae Marino wrote:

  Hi Users,
   
  trying to clarify some specs on the renderbin, perhaps someone
could help:
   
  what I'm assuming:
  -there are two default renderbins created at startup "RenderBin"
and "DepthSortedBin"
  -"DepthSortedBin" is always render after "RenderBin"
  -"DepthSortedBin" sorts objects from back to front
  -higher renderbin number means rendering is done later
  -renderbins are sorted by states
   
  what I'm asking:
  -if an object has a parent osg::Group that has been set to
"RenderBin" with a value of 10 and the object itself uses 
  "RenderBin" with a value of 20 then which is used?


RenderBins are nested. If a node has a bin number different from the
current render bin (or its StateSet render bin mode is set
to override), a new render bin is created and is added to the current
render bin. It become the current render bin.

So, if a node has a bin number of 20 and it is different from the
current bin number, a render bin 20 is added to the current
render bin.


  -an .osg file can have renderbin values too? so if I load an
.osg file and set it to have "RenderBin" 10 do I override the renderbin
values
  in the file? or are they pushed relative to my given value 10?
sometimes the .osg file consist of many renderbin values. 
  
  


An osg file can contain render bin values. If you load an osg file and
set the render bin number of the root node to 10, you don't
override the render bin numbers of the nodes (or just the render bin
number of the root node). Because render bins are nested
during the scene culling, it will force the cull visitor to create a
specific render bin for the whole sub-graph.


  -- 
Regards,
Peter Wraae Marino
  
  www.osghelp.com
- OpenSceneGraph support site
  
  

___
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] Test Paged database online

[Lionel Lagarde]

I don't think that is a connection problem. libcurl download the
file integrally in a stringstream.
The stringstream is then given to to ive ReaderWriter.

Serge Lages wrote:
Hi all,
  
Can't test myself currently but I'll try as soon as I can.
About the error, are you behind proxies or something similar ? Is it
possible to be a connection problem ?
  
  On Tue, Oct 28, 2008 at 5:16 PM, Gerrick
Bivins <[EMAIL PROTECTED]>
wrote:
  I
get this error on Mac OSX 10.5

DataInputStream::readCharArray(): Failed to read char value.

./bin/osgviewer.app/Contents/MacOS/osgviewer: No data loaded

 Gerrick


On 10/28/08 11:13 AM, "Jean-Sébastien Guay"
<[EMAIL PROTECTED]>
wrote:

> Hi Robert,
>
>> The readsome() returns if data isn't available yet, it doesn't
wait
>> like read.  You could try changing the code across to using
read() and
>> gcount() to find out how many bytes have been read.
>>
>> What platform are you working on?
>
> Just to add another report, I get the same error as Lionel:
>
> DataInputStream::readCharArray(): Failed to read char value.
>
> I'm using the zlib binary that was in Mike's 3rdParty binaries for
> Visual Studio 8.0 SP1, which I think is the one that was compiled
with
> libpng (not built separately). Not sure if that has any bearing on
the
> problem, just thought I'd mention it.
>
> I don't have time to debug this myself, so I'll hang back and let
others
> puzzle it out. I can give plenty of moral support though! :-)
>
> J-S



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


  
  
  
  
  
-- 
Serge Lages
  http://www.tharsis-software.com
  

___
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] Test Paged database online

[Lionel Lagarde]

Curiously, the readsome function fail to read data (return value is 0),
but fin.eof() returns false.

I've tried to loop until some data are read but it does not work :

do {
   strm.avail_in = fin.readsome((char*)in, CHUNK);
while (strm.avail_in == 0 && !fin.eof());

It is an infinite loop.


The behavior is the same using a local file. Maybe my zlib doesn't work.



Lionel Lagarde wrote:

The ive plugin is built with zlib support.

There is a problem in the uncompress loop. The earth.ive size is 14976 
bytes.

In the loop, the first read:

strm.avail_in = fin.readsome((char*)in, CHUNK);

reports me 12427 bytes read and the second 0 bytes.

Continuing investigation.

John Vidar Larring wrote:

Hi Robert,

After compiling OSG svn trunk (linux 64bit), the following commands 
worked like charm:


> wget http://www.openscenegraph.org/data/earth_bayarea/bay.path
> osgviewer 
http://www.openscenegraph.org/data/earth_bayarea/earth.ive -p 
bay.path --file-cache MyFileCache


The second time I ran the viewer, it was obvious that the file cache 
was being used.


Great features!
/ John

Robert Osfield wrote:

Hi All,

Last night I uploaded a 547Mb paged database to openscenegraph.org.
The .ive files are all generated using zlib compression that is built
into the svn/trunk version of the OSG, you won't be able to load them
with any prior version of the OSG I'm afraid as the compression
support has just been introduced.  To view the database you can use:

  osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive


The database I generated with the svn/trunk version of
VirtualPlanetBuilder, using options to generate the compressed data,
to use non power of two textures for the highest res tiles, and
disabled mipmapping.   These options all work to minimize the tile
sizes which in turn means that the data is better suited for streaming
over http.

The data itself is composed of the Nasa blue marble 1km data, with
high res insert in the bay area of california.  You should be able to
find the Don Burn's local hang gliding hill that the osghangglide
example is based on, which in turn was the original inspiration for
the whole OpenSceneGraph odyssey.  To help find this little insert
I've uploaded an animation path:

http://www.openscenegraph.org/data/earth_bayarea/bay.path

Grab this then run osgviewer with the path:

osgviewer 
http://www.openscenegraph.org/data/earth_bayarea/earth.ive

-p bay.path

This will set up an AnimationPathManipulator that zooms you into the
high res insert, and then around the globe.  Pressing '4' will take
you to the TerrainManipulator so you can then start exploring
manually, pressing '5' will take you back to the animation path.

The next little thing your can try is to populate a local file cache,
so the next time you load up the data you can pick up on locally cache
files rather than hitting the server.

osgviewer 
http://www.openscenegraph.org/data/earth_bayarea/earth.ive

--file-cache MyFileCache

Or via an env var:

export OSG_FILE_CACHE = /home/me/Data/MyFileCache  # change to
setenv or set for your system...
osgviewer 
http://www.openscenegraph.org/data/earth_bayarea/earth.ive


Now this dataset is really a tiny one compared to what
VirtualPlanetBuilder is capable of building, one I routinely test
against is 20,000 times bigger, alas the data isn't public so you'll
just have to find your own data and build your databases for such a
Terrabyte database.  All the tools are there for you, you just need to
add the data.  In terms of runtime need to view the bigger datasets
there are no differences, osgviewer works for all of them equally.

Have fun.

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] Test Paged database online

[Lionel Lagarde]

The ive plugin is built with zlib support.

There is a problem in the uncompress loop. The earth.ive size is 14976 
bytes.

In the loop, the first read:

strm.avail_in = fin.readsome((char*)in, CHUNK);

reports me 12427 bytes read and the second 0 bytes.

Continuing investigation.

John Vidar Larring wrote:

Hi Robert,

After compiling OSG svn trunk (linux 64bit), the following commands 
worked like charm:


> wget http://www.openscenegraph.org/data/earth_bayarea/bay.path
> osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive 
-p bay.path --file-cache MyFileCache


The second time I ran the viewer, it was obvious that the file cache 
was being used.


Great features!
/ John

Robert Osfield wrote:

Hi All,

Last night I uploaded a 547Mb paged database to openscenegraph.org.
The .ive files are all generated using zlib compression that is built
into the svn/trunk version of the OSG, you won't be able to load them
with any prior version of the OSG I'm afraid as the compression
support has just been introduced.  To view the database you can use:

  osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive


The database I generated with the svn/trunk version of
VirtualPlanetBuilder, using options to generate the compressed data,
to use non power of two textures for the highest res tiles, and
disabled mipmapping.   These options all work to minimize the tile
sizes which in turn means that the data is better suited for streaming
over http.

The data itself is composed of the Nasa blue marble 1km data, with
high res insert in the bay area of california.  You should be able to
find the Don Burn's local hang gliding hill that the osghangglide
example is based on, which in turn was the original inspiration for
the whole OpenSceneGraph odyssey.  To help find this little insert
I've uploaded an animation path:

http://www.openscenegraph.org/data/earth_bayarea/bay.path

Grab this then run osgviewer with the path:

osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive
-p bay.path

This will set up an AnimationPathManipulator that zooms you into the
high res insert, and then around the globe.  Pressing '4' will take
you to the TerrainManipulator so you can then start exploring
manually, pressing '5' will take you back to the animation path.

The next little thing your can try is to populate a local file cache,
so the next time you load up the data you can pick up on locally cache
files rather than hitting the server.

osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive
--file-cache MyFileCache

Or via an env var:

export OSG_FILE_CACHE = /home/me/Data/MyFileCache  # change to
setenv or set for your system...
osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive

Now this dataset is really a tiny one compared to what
VirtualPlanetBuilder is capable of building, one I routinely test
against is 20,000 times bigger, alas the data isn't public so you'll
just have to find your own data and build your databases for such a
Terrabyte database.  All the tools are there for you, you just need to
add the data.  In terms of runtime need to view the bigger datasets
there are no differences, osgviewer works for all of them equally.

Have fun.

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] Test Paged database online

[Lionel Lagarde]

Hi Robert,

osgviewer reports me:

DataInputStream::readCharArray(): Failed to read char value.

Do I need to do something to enable the zlib decompression ?

Robert Osfield wrote:

Hi All,

Last night I uploaded a 547Mb paged database to openscenegraph.org.
The .ive files are all generated using zlib compression that is built
into the svn/trunk version of the OSG, you won't be able to load them
with any prior version of the OSG I'm afraid as the compression
support has just been introduced.  To view the database you can use:

  osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive


The database I generated with the svn/trunk version of
VirtualPlanetBuilder, using options to generate the compressed data,
to use non power of two textures for the highest res tiles, and
disabled mipmapping.   These options all work to minimize the tile
sizes which in turn means that the data is better suited for streaming
over http.

The data itself is composed of the Nasa blue marble 1km data, with
high res insert in the bay area of california.  You should be able to
find the Don Burn's local hang gliding hill that the osghangglide
example is based on, which in turn was the original inspiration for
the whole OpenSceneGraph odyssey.  To help find this little insert
I've uploaded an animation path:

http://www.openscenegraph.org/data/earth_bayarea/bay.path

Grab this then run osgviewer with the path:

osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive
-p bay.path

This will set up an AnimationPathManipulator that zooms you into the
high res insert, and then around the globe.  Pressing '4' will take
you to the TerrainManipulator so you can then start exploring
manually, pressing '5' will take you back to the animation path.

The next little thing your can try is to populate a local file cache,
so the next time you load up the data you can pick up on locally cache
files rather than hitting the server.

osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive
--file-cache MyFileCache

Or via an env var:

export OSG_FILE_CACHE = /home/me/Data/MyFileCache  # change to
setenv or set for your system...
osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive

Now this dataset is really a tiny one compared to what
VirtualPlanetBuilder is capable of building, one I routinely test
against is 20,000 times bigger, alas the data isn't public so you'll
just have to find your own data and build your databases for such a
Terrabyte database.  All the tools are there for you, you just need to
add the data.  In terms of runtime need to view the bigger datasets
there are no differences, osgviewer works for all of them equally.

Have fun.

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] How to Monitor VideoMemory usage

[Lionel Lagarde]

try
http://nuclearplayground.com/NuclearPlayground/MemStatus/content.php


Jason Daly wrote:

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


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Paged simulation and culling performance drop

[Lionel Lagarde]

The requests queuing in the database pager didn't work.



Robert Osfield wrote:

  On Thu, Jun 26, 2008 at 5:48 PM, Lionel Lagarde <[EMAIL PROTECTED]> wrote:
  
  
It didn't work !!!

  
  
What didn't work??

  
  
I've queued the database requests in the requestNodeFile method. These
requests are merged
in the DatabasePager lists in the run method using a little lock (just the
time of a pop).

Continuing my investigations ...

  
  ___
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] Paged simulation and culling performance drop

[Lionel Lagarde]

It didn't work !!!

I've queued the database requests in the requestNodeFile method. These
requests are merged
in the DatabasePager lists in the run method using a little lock (just
the time of a pop).

Continuing my investigations ...



Lionel Lagarde wrote:

  
  I know that I have to moving to the latest OSG
but
I can't do it for the moment.
  
I will look at the SVN DatabasePager request method.
  
Robert Osfield wrote:
  
On Thu, Jun 26, 2008 at 4:20 PM, Lionel Lagarde <[EMAIL PROTECTED]> wrote:
  

  I'm using OSG 2.0.

I agree that database requests could be very costly when the request
queue (or the to compile list or the to merge list) are too big.
But I've benched the requestNodeFile method and it doesn't take
too much time.



I doubt you are coming up against a different issue than the one that
I profiled and then fixed during the refactor of DatabasePager, so I
would expect moving the latest OSG in SVN or 2.5.1 would fix you
performance issue.   Moving from 2.0 to the latest OSG should not be
difficult, as the vast majority of the API has not been changed.

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] Paged simulation and culling performance drop

[Lionel Lagarde]

I know that I have to moving to the latest OSG but
I can't do it for the moment.

I will look at the SVN DatabasePager request method.

Robert Osfield wrote:

  On Thu, Jun 26, 2008 at 4:20 PM, Lionel Lagarde <[EMAIL PROTECTED]> wrote:
  
  
I'm using OSG 2.0.

I agree that database requests could be very costly when the request
queue (or the to compile list or the to merge list) are too big.
But I've benched the requestNodeFile method and it doesn't take
too much time.

  
  
I doubt you are coming up against a different issue than the one that
I profiled and then fixed during the refactor of DatabasePager, so I
would expect moving the latest OSG in SVN or 2.5.1 would fix you
performance issue.   Moving from 2.0 to the latest OSG should not be
difficult, as the vast majority of the API has not been changed.

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] Paged simulation and culling performance drop

[Lionel Lagarde]

I'm using OSG 2.0. 

I agree that database requests could be very costly when the request
queue (or the to compile list or the to merge list) are too big.
But I've benched the requestNodeFile method and it doesn't take
too much time.


Robert Osfield wrote:

  Hi Lionel,

Which version of the OSG are you using?

Prior to rewrite of the DatabasePager in 2.5.x and SVN the pager used
to have occasional problems in high cull times when large numbers of
database requests backed up, which meant that the search operation
that was done on each frame for each fresh request could become costly
- it was in effect an O(N squared) relationship.  When only a small
number of requests are outstanding the cost is small, but when they
pile up the cull cost quickly grows.

In new DatabasePager there code has been refactored so there isn't a
search required anymore, so the wayward cull costs are avoided
completely.

Robert.

On Thu, Jun 26, 2008 at 3:43 PM, Lionel Lagarde <[EMAIL PROTECTED]> wrote:
  
  
Hi,

I'm running a simulation on a huge paged database. It works fine, the frame
rate is
constant, and the terrain is paged correctly.

But sometimes, the culling pass takes ages to complete. Most of the time, it
takes
2/3 ms to complete, but it could take up to 40/60 ms to build the render
graph/stage.

Anybody has an idea on what happen ?

I've measured the time passed in the PagedLOD database requests but it is
very small.

When the problem appears, the RenderLeaf cache of the CullVisitor doesn't
grow dramatically
and the number of nodes traversed by the CullVisitor doesn't change.

I don't know where to look now.
Please help ...

___
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

[osg-users] Paged simulation and culling performance drop

[Lionel Lagarde]

Hi, 

I'm running a simulation on a huge paged database. It works fine, the
frame rate is 
constant, and the terrain is paged correctly.

But sometimes, the culling pass takes ages to complete. Most of the
time, it takes
2/3 ms to complete, but it could take up to 40/60 ms to build the
render graph/stage.

Anybody has an idea on what happen ?

I've measured the time passed in the PagedLOD database requests but it
is very small.

When the problem appears, the RenderLeaf cache of the CullVisitor
doesn't grow dramatically
and the number of nodes traversed by the CullVisitor doesn't change. 

I don't know where to look now.
Please help ...



___
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

[Lionel Lagarde]

Everything looks ok regarding freetype now. I've
reinstalled SP1 patch and the plugin
load correctly in debug and release builds.

Unfortunately I can't use VC 2005 SP1 because it means upgrade all the
developpers
PCs are re-validate all our OSG based softs. So I go back to VC 2005
without SP1 and
I compiled using gnuwin32 dependencies. It works.

Jean-Sébastien Guay wrote:
Bonjour
Vincent,
  
  
      This morning I'm trying to compil osg
2.5.1 with Cmake 2.6 and

    visual studio 2005 SP1 (and last 3rdparty from SVN for vs80 sp1).

    I'll tell you if everything is good.



Everything looks fine.

No problems.

  
  
Excellent, good to know it's all working for you now.
  
  
J-S
  



___
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

[Lionel Lagarde]

Linking osgdb_freetype with freetype235.lib (not
freetype235_D.lib) works. I hope
this will not lead to crt conflict.

Vincent Bourdier wrote:
Hi, with osg 2.4 it solves the problem !
All seems to be good now.
  
I'll try with osg 2.5.1 tomorrow...
  
Gordon, did you verify your VS proj is configured for dll multithread ?
  
  2008/6/5 Lionel Lagarde <[EMAIL PROTECTED]>:
  
Hi, 

I have a similar problem.

The debug build of OSG is unable to load the osgdb_freetype plugin.
The release build has no problem with this plugin.

I'm using visual express 2005 SP1. The dependency walker tool from
microsoft says
that msvcp80d.dll and msvcp80d.dll are missing.

I don't know what to do. Most of the threads on this subject say that
it's a SP1 issue.
Maybe I should reinstall my compiler.

Vincent, could you reply this thread if you find any solution.


Gordon Tomlinson wrote:

  
  
  Basically you can not use VS SP1
libs with a no SP1 Applications
   
  You can use non SP1 libs with
SP1 applications in some cases,
   
  But I would highly suggest you
always use either ALL SP1 libs or ALL none SP1 libs ( you will have to
build all 3rd party files to match)
   
  I would also recommend any one
using VS2005 upgrade to Sp1, it fixes alot of issues and saves much
grief
   
  
  
  __
  Gordon Tomlinson 
  
  Email   : [EMAIL PROTECTED]
  Website : www.vis-sim.com
  www.gordontomlinson.com  
  __
  
  "Self
defence is not a function of learning tricks 
but is a function of how quickly and intensely one 
can arouse one's instinct for survival" 
  -Master
Tambo Tetsura 
  
  
   
  
  
  From:
  [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
  On Behalf Of Vincent
Bourdier
  Sent: 05 June 2008 12:55
  To: OpenSceneGraph Users
  Subject: Re: [osg-users] Unable to find plugin
  
  
Hi Mattias,
  
Yes I added myself some path for the linker to be sure it was not the
problem...
Before compiling all OSG once again, I'll try to put the SP1 on Visual
Studio as suggested by Collin. Don't know why but I thing It is a
problem like this, because OSG compiles very well and the .dll are
generated
  
Thanks for help,
  
I'll tell you when I resolve the problem.
  
Regards,
  Vincent.
  
  2008/6/5 Mattias Helsing <[EMAIL PROTECTED]>:
  Hi
Vincent,

I'd spend a buck on Colin's reply.

Though it's a bit odd that you have 3rdParty../include/freetype in
your include path. I guess you have added this yourself in CMake
setup. The freetype plugin just includes ft2build.h which is in
3rdParty/include. It probably won't hurt of course, just a notice.

You don't report what output you get when setting
OSG_NOTIFY_LEVEL=DEBUG_INFO. Anything ?

cheers
Mattias



On 6/5/08, Vincent Bourdier <[EMAIL PROTECTED]>
wrote:
> The problem still here :
>
> My PATH :
>
Z:\OSG_2.4\binaries\bin;Z:\OSG_2.4\binaries\bin\osgplugins-2.4.0;Z:\OSG_2.4\sources\3rdParty\bin;
>
> Osg 2.4 Freetype compilation : ok. No error, no warnings
>
> in my project :
> linker  : Z:\OSG_2.4\sources\3rdParty\lib;Z:\OSG_2.4\binaries\lib;
> include :
>
\OSG_2.4\sources\3rdParty\include\freetype;Z:\OSG_2.4\sources\3rdParty\include;Z:\OSG_2.4\sources\OpenSceneGraph-src\include;
>
> And still the error messages :
> "Could not find plugin to read object from file ... arial.ttf"
> "Could not find plugin to read object from file ... picture.jpg"
> "Could not find plugin to read object from file ... picture.png"
>
> I don't know where to search now...
>
> Any idea ?
>
> Regards,
>    Vincent.
>
> 2008/6/5 Mattias Helsing <[EMAIL PROTECTED]>:
>
>> Hi Vincent,
>>
>> is 3rdPart.../bin in your path when you run?
>>
>> CMake should pick up the FREETYPE_INCLUDE_DIR if you give a
proper
>> value to ACTUAL_3RDPARTY_DIR.
>>
>> What messages do you get when you set OSG_NOTIFY_LEVEL to
DEBUG_INFO
>>
>> cheers
>> MAttias
>>
>> On 6/5/08, Vincent Bourdier <[EMAIL PROTECTED]>
wrote:
>> > Hi,
>> >
>> > After download of the last 3rdParty from SVN, I've some
problem on
>> > compilation :
>> > In the Cmake 2.4 config, with advanced values, Freetype
ask for
>> > *FREETYPE_INCLUDE_DIR_freetype2
>> > *and I didn't found something about that... If I put some
directory like
>> > 3rdParty_win32binaries_vs80sp1/include/freetype... it
compile, but
>> &g

Re: [osg-users] Unable to find plugin

[Lionel Lagarde]

Hi, 

I have a similar problem.

The debug build of OSG is unable to load the osgdb_freetype plugin.
The release build has no problem with this plugin.

I'm using visual express 2005 SP1. The dependency walker tool from
microsoft says
that msvcp80d.dll and msvcp80d.dll are missing.

I don't know what to do. Most of the threads on this subject say that
it's a SP1 issue.
Maybe I should reinstall my compiler.

Vincent, could you reply this thread if you find any solution.


Gordon Tomlinson wrote:

  
  
  Basically you can not use VS SP1
libs with a no SP1 Applications
   
  You can use non SP1 libs with
SP1 applications in some cases,
   
  But I would highly suggest you
always use either ALL SP1 libs or ALL none SP1 libs ( you will have to
build all 3rd party files to match)
   
  I would also recommend any one
using VS2005 upgrade to Sp1, it fixes alot of issues and saves much
grief
   
  
  
  __
  Gordon Tomlinson 
  
  Email   : [EMAIL PROTECTED]
  Website : www.vis-sim.com
www.gordontomlinson.com 
  
  __
  
  "Self
defence is not a function of learning tricks 
but is a function of how quickly and intensely one 
can arouse one's instinct for survival" 
  -Master
Tambo Tetsura 
  
  
   
  
  
  From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Vincent
Bourdier
  Sent: 05 June 2008 12:55
  To: OpenSceneGraph Users
  Subject: Re: [osg-users] Unable to find plugin
  
  
Hi Mattias,
  
Yes I added myself some path for the linker to be sure it was not the
problem...
Before compiling all OSG once again, I'll try to put the SP1 on Visual
Studio as suggested by Collin. Don't know why but I thing It is a
problem like this, because OSG compiles very well and the .dll are
generated
  
Thanks for help,
  
I'll tell you when I resolve the problem.
  
Regards,
  Vincent.
  
  2008/6/5 Mattias Helsing <[EMAIL PROTECTED]>:
  Hi
Vincent,

I'd spend a buck on Colin's reply.

Though it's a bit odd that you have 3rdParty../include/freetype in
your include path. I guess you have added this yourself in CMake
setup. The freetype plugin just includes ft2build.h which is in
3rdParty/include. It probably won't hurt of course, just a notice.

You don't report what output you get when setting
OSG_NOTIFY_LEVEL=DEBUG_INFO. Anything ?

cheers
Mattias



On 6/5/08, Vincent Bourdier <[EMAIL PROTECTED]>
wrote:
> The problem still here :
>
> My PATH :
>
Z:\OSG_2.4\binaries\bin;Z:\OSG_2.4\binaries\bin\osgplugins-2.4.0;Z:\OSG_2.4\sources\3rdParty\bin;
>
> Osg 2.4 Freetype compilation : ok. No error, no warnings
>
> in my project :
> linker  : Z:\OSG_2.4\sources\3rdParty\lib;Z:\OSG_2.4\binaries\lib;
> include :
>
\OSG_2.4\sources\3rdParty\include\freetype;Z:\OSG_2.4\sources\3rdParty\include;Z:\OSG_2.4\sources\OpenSceneGraph-src\include;
>
> And still the error messages :
> "Could not find plugin to read object from file ... arial.ttf"
> "Could not find plugin to read object from file ... picture.jpg"
> "Could not find plugin to read object from file ... picture.png"
>
> I don't know where to search now...
>
> Any idea ?
>
> Regards,
>    Vincent.
>
> 2008/6/5 Mattias Helsing <[EMAIL PROTECTED]>:
>
>> Hi Vincent,
>>
>> is 3rdPart.../bin in your path when you run?
>>
>> CMake should pick up the FREETYPE_INCLUDE_DIR if you give a
proper
>> value to ACTUAL_3RDPARTY_DIR.
>>
>> What messages do you get when you set OSG_NOTIFY_LEVEL to
DEBUG_INFO
>>
>> cheers
>> MAttias
>>
>> On 6/5/08, Vincent Bourdier <[EMAIL PROTECTED]>
wrote:
>> > Hi,
>> >
>> > After download of the last 3rdParty from SVN, I've some
problem on
>> > compilation :
>> > In the Cmake 2.4 config, with advanced values, Freetype
ask for
>> > *FREETYPE_INCLUDE_DIR_freetype2
>> > *and I didn't found something about that... If I put some
directory like
>> > 3rdParty_win32binaries_vs80sp1/include/freetype... it
compile, but
>> > after, during the run, I've the "*could not find plugin
to read
>> > arial.ttf" *message and so I don't know how to make a
good 2.4
>> > compilation, with freetype, jpeg and png plugins.
>> >
>> > Thanks,
>> >
>> > Regards,
>> >    Vincent.
>> >
>> > 2008/6/4 Vincent Bourdier <[EMAIL PROTECTED]>:
>> >
>> >> Thanks Jean-Sébatien, I'm currently downloading the
good 3dParties from
>> >> SVN... it looks better :)
>> >>
>> >> I'll try to compile just after.
>> >>
>> >> Thanks for theses good indications
>> >>
>> >> Vincent.
>> >>
>> >> 2008/6/4 Paul Melis <[EMAIL PROTECTED]>:
>> >>
>> >>> Jean-Sébastien Guay wrote:
>> >>>
>> >>>
>> >>>  Hello Vincent,
>> 
>>   I didn't found some osgbd_ttf.dll in the
plugins... in 2.2, 2.4,
>> 2.5.1
>> > What is the plugin which define it ?
>> >
>> 
>> 
>>  I think Paul made a small mistake, it's not
osgdb_ttf.dll, it's
>>  osgdb_freetype.dll that you're looking for.
This should exist to be
>> able
>>  to
>>  load ttf fonts.
>

[osg-users] PrecipitationEffect and antialiasing

[Lionel Lagarde]

Hi,

I'm adding precipitations in our application and I'm very surprised by 
the performance differences when I use different antialiasing settings.

Configuration: Core 2 duo 6400 / GeForce 7900 GTX

I run the command "osgprecipitation cow.osg"

No AA: 587 Hz (initial view) 2380 Hz (viewed from above)
2x:554 Hz (initial view) 2046 Hz (viewed from above)
4x:480 Hz (initial view) 1530 Hz (viewed from above)
8xS: 2 Hz (initial view)  440 Hz (viewed from above)

The anisotropic filtering also reduce the performances.

Can someone confirm these results.

Why does the camera position impact the frame rate ?
Is there some "things" that are not rendered when the raindrops are seen 
from above ?

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] RW ive exceptions

[Lionel Lagarde]

Hi,

My application is an helicopter simulator on huge terrain database. The 
terrain is paged.

OSG and the application are compiled with VC 2005 express.

On the development machines, the application works fine.

On the simulation machines (where VC express is not installed, only 
vcredist_x86 is installed), some errors occur in the DatabasePager thread.

The errors come from the ive RW plugin:
"Error reading file: DataInputStream::readChar(): Failed to read XXX value."

Errors don't happen all the time and when they occur, the current read 
file is always different.

I don't know where and what I should look for.

Any ideas ?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Asynchronous file loading via DatabasePager questions

[Lionel Lagarde]

Tim Moore wrote:


The other thing to keep in mind is that readNodeFile and friends aren't 
necessarily
thread safe, but you don't have access to the lock that the pager uses to 
serialize
access to those functions. Either you stop doing any file loading calls from 
your main
thread once the pager has started, or you need to do the locking yourself by 
installing
read callback functions that do the locking. The bugs you're seeing sound like 
random
corruption of this kind.



I believed that osgDB::Registry operations were thread safe. The plugins may
not be thread safe but the registry has to be thread safe.
No ?


Tim Moore wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Colin Branch wrote:
  

Hi all,

What I'm trying to do:
Asynchronous model loading using OSG 2.2

How I'm currently doing it:
I'm trying to use the Database Pager's requestNodeFile.


I just did this for the FlightGear project and it works well there.
  
I created a new node class that I can add (as well as place temporary 
objects) that I can add and will stay in the scene.


class DtDelayedModelNode : public osg::Group
{
...
DtDelayedModelNode(const std::string& filename, osgDB::DatabasePager* 
pager) : osg::Group()

{
osg::FrameStamp fs;
fs.setFrameNumber(INT_MAX);
pager->requestNodeFile(filename,this,1.0,&fs);
}
...
};



For this application you probably do want to check out ProxyNode as Bryan Thrall
suggested. If I had known about ProxyNode I might have used it instead of 
calling
requestNodeFile directly.

What you've done here won't reliably work. You need to call requestNodeFile 
every frame
until your request is satisfied. You will only find this out by looking closely 
at the
implementation of ProxyNode and PagedLOD or by googling in the mailing list :)

  

Problems:
#1 Very limited documentation of the Pager class and no example on how 
to use it.   I've searched the osgusers archive but haven't found 
anything too helpful, the 1.x examples don't seem relevant anymore.


See above about ProxyNode and PagedLOD.
  
#2 Occasional texture corruption.  This is difficult to reproduce 
however it appears that sometimes the width of the texture is 1px 
creating a streaking effect.
#3 Certain actions cause the main app to lock, for example bringing up 
the Stats HUD.


The other thing to keep in mind is that readNodeFile and friends aren't 
necessarily
thread safe, but you don't have access to the lock that the pager uses to 
serialize
access to those functions. Either you stop doing any file loading calls from 
your main
thread once the pager has started, or you need to do the locking yourself by 
installing
read callback functions that do the locking. The bugs you're seeing sound like 
random
corruption of this kind.
  

Questions:
Is the Database Pager the proper way to be doing this?


It works for the FlightGear flight simulator project. I created a very small 
subclass
of DatabasePager in order to have access to the _childrenToDeleteList of the 
pager.

  
What if any calls should I make to the pager around frame() (ie it 
doesn't appear that startFrame endFrame are needed, any other calls)?




None if you're using osgViewer. Otherwise look closely at the osgViewer::Viewer 
source
code.

  
The value of the frame stamp appears to control deletion of requests. Ie 
if I pass in the current frame stamp, the model is actually deleted in 
compileGLObjects. Unless I set it to some value in the future (currently 
using INT_MAX) I can't guarantee it will load. Could someone explain the 
purpose of the framestamp and the proper usage?


See above. Normally you check every frame if a request has been satisfied; if 
not, you
make it again with the current frame stamp. The OSG clients of DatabasePager, 
ProxyNode
and PagedLOD, make these requests from the cull traversal, so this usage gives 
a way
to cancel a request if the object drops out of the field of view.
  

Is there anyway to get status feedback while a file loads?


You can tell if a load is completed by checking if an object has been added to 
the group
you passed to requestNodeFile. Otherwise no, though you could arrange for the 
readNodeFile
callback you're going to write :) to return an empty error object of some kind.

Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHY5HHeDhWHdXrDRURAqMHAJ9EwsSEmq/km+Kmm66vQR7QHypqxgCfXtcb
AYMB1dGywN0upP0wEE9JErc=
=mNg5
-END PGP SIGNATURE-
___
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] slow loading with DatabasePager and a model library

[Lionel Lagarde]

The SharedStateManager modify the newly loaded database. Move the 
SharedStateManager
calls in the DatabasePager thread can cause multi-threading issues.

It can be resolved using the ReadResult status: share the textures only on
FILE_LOADED_FROM_CACHE loading results. But the loaded database can contain
already loaded external references.

So the SharedStateManager have to detect already processed sub-graph or 
StateSet.


Tim Moore wrote:
> Great! I'm really looking forward to seeing these changes. Did you see any 
> reason that
> the SharedStateManger couldn't be run in the pager, before compilation? I 
> also saw the
> linear search for textures and think it could be changed easily to use a map.
>
> Tim
>   

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] slow loading with DatabasePager and a model library

[Lionel Lagarde]

Hi,

I modified DatabasePager.cpp to avoid recompilation of the already compiled
drawables and textures. Once I've finished cleaning the file, I'll send it
to submission.

For StateSet sharing, I don't use the SharedStateManager because it process
the loaded database after its compilation and it is done in the main thread.
The SharedStateManager also performs linear searches to retrieve shared 
textures.




Robert Osfield wrote:

Hi Tim,

  

Fedora, 3 Ghz dual processor P4, 8800 GTS. I don't have any I/O worries about 
the
machine; other OSG sample programs and databases run fine.



A pretty reasonable machine and OS so its not one would suspect
general problems with compiling display lists etc.

Another thing you could try is to enable compile contexts.  Have a
look at osgviewer.cpp to see how it switches it one when you use the
--cc option.

As a general note, the DatabasePager is designed to try and maintain
constant framerates and does so by balance how much data is
compiled/deleted on each frame - you've already played with the
various parameters so will have a bit of grasp of this already.  I
wrote DatabasePager and do testing and optimizing on it with the data
I can get my hands on - most of which is data generated by
osgdem/VirtualPlanetBuilder.  These databases are pretty regular, and
specifically designed with paging in mind so most probably won't be
stressing the DatabasePager in the same way that your own datasets.

Since my the types of data I have access is a not as wide ranging as
the types of data and machines/OS as the community at large can test
against I have to rely upon members of the community to pitch in with
helping characterise issues and with the optimization of paging
support. So I'm open to suggestions on improvements.

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] State problem

[Lionel Lagarde]

Hi, 

I'm running osgviewer (2.0 and 2.2) with the attached OSG file.

The file is composed of 4 drawables. Each drawable defines its own
StateSet.
The last drawable material is:

Material {
  DataVariance UNSPECIFIED
  ColorMode OFF
  ambientColor 1 1 1 1
  diffuseColor 1 0 0 1
  specularColor 0 0 1 1
  emissionColor 0 1 0 1
  shininess 10
}

But the emissive part is not taken into account.
Curiously, the first frame is correct. The corresponding quad is yellow.
In the other frames, the quad is red.

If I remove one or more drawable, or if I change the order of the
drawables
in the file, the quad is correctly rendered.


The bad image:


What it should be (I've removed the first drawable):


Please help !!!


Group {
  DataVariance UNSPECIFIED
  name "dummy:root"
  nodeMask 0x
  cullingActive TRUE
  num_children 1
  Geode {
DataVariance UNSPECIFIED
name "dummy:geode"
nodeMask 0x1
cullingActive TRUE
num_drawables 4
Geometry {
  DataVariance STATIC
  name "dummy:geode:geom0"
  StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
  GL_LIGHTING ON
Material {
  DataVariance UNSPECIFIED
  name "INH18L75.rgbvisible"
  ColorMode AMBIENT_AND_DIFFUSE
  ambientColor 1 1 1 1
  diffuseColor 1 1 1 1
  specularColor 0 0 0 1
  emissionColor 0 0 0 1
  shininess 0
}
  }
  useDisplayList TRUE
  useVertexBufferObjects FALSE
  PrimitiveSets 1
  {
DrawElementsUByte QUADS 4
{
  0 1 2 3
}
  }
  VertexArray Vec3Array 4
  {
-30 -30 0
  0 -30 0
  0 0 0
  -30 0 0
  }
  NormalBinding PER_VERTEX
  NormalArray Vec3Array 4
  {
0 0 1
0 0 1
0 0 1
0 0 1
  }
}
Geometry {
  DataVariance STATIC
  name "dummy:geode:geom1"
  StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
  GL_LIGHTING ON
Material {
  DataVariance UNSPECIFIED
  name "RAIL1.rgbvisible"
  ColorMode AMBIENT_AND_DIFFUSE
  ambientColor 1 1 1 1
  diffuseColor 1 1 1 1
  specularColor 0 0 0 1
  emissionColor 0 0 0 1
  shininess 0
}
  }
  useDisplayList TRUE
  useVertexBufferObjects FALSE
  PrimitiveSets 1
  {
DrawElementsUByte QUADS 4
{
  0 1 2 3
}
  }
  VertexArray Vec3Array 4
  {
  0 -30 0
  30 -30 0
  30 0 0
  0 0 0
  }
  NormalBinding PER_VERTEX
  NormalArray Vec3Array 4
  {
0 0 1
0 0 1
0 0 1
0 0 1
  }
}
Geometry {
  DataVariance STATIC
  name "IMM:geode0::geom"
  StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHTING ON
Material {
  DataVariance UNSPECIFIED
  ColorMode OFF
  ambientColor 1 1 1 1
  diffuseColor 1 1 1 1
  specularColor 0 0 0 1
  emissionColor 0 0 0 1
  shininess 0
}
  }
  useDisplayList TRUE
  useVertexBufferObjects FALSE
  PrimitiveSets 1
  {
DrawArrays QUADS 0 4
  }
  VertexArray Vec3Array 4
  {
-13.5 0 26
-6 0 26
-6 0 27
-13.5 0 27
  }
  NormalBinding PER_VERTEX
  NormalArray Vec3Array 4
  {
0 -1 0
0 -1 0
0 -1 0
0 -1 0
  }
}
Geometry {
  DataVariance STATIC
  name "IMM:geode1:geom"
  StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHTING ON
Material {
  DataVariance UNSPECIFIED
  ColorMode OFF
  ambientColor 1 1 1 1
  diffuseColor 1 0 0 1
  specularColor 0 0 1 1
  emissionColor 0 1 0 1
  shininess 10
}
  }
  useDisplayList TRUE
  useVertexBufferObjects FALSE
  PrimitiveSets 1
  {
DrawArrays QUADS 0 4
  }
  VertexArray Vec3Array 4
  {
  -15 -15 3
  15 -15 3
  15 15 3
  -15 15 3
  }
  NormalBinding PER_VERTEX
  NormalArray Vec3Array 4
  {
0 0 1
0 0 1
0 0 1
0 0 1
  }
}
  }
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] DatabasePager - Display list compilation

[Lionel Lagarde]

Hi,

When the database pager is requested to compile the paged drawables, (in 
the DatabasePager::compileGLObjects method) it calls the 
compileGLObjects method of the drawable contained in the DataToCompile map.

This method delete the display list of the drawable if it already exists.
In the case of multi instance paged drawables (trees for example), the 
database pager compile and recompile and rerecompile the same drawable 
for each request.

It takes time and eats the _maximumNumOfObjectsToCompilePerFrame counter.

Maybe the FindCompileableGLObjectsVisitor can check if the drawable has 
already been compiled.

The same thing can be made for texture compilation. They are not 
re-uploaded in the video memory if the image hasn't been modified by the 
DatabasePager try to compile them and
eat the _maximumNumOfObjectsToCompilePerFrame counter.


I don't see in the code where the VBO geometries are compiled. The VBO 
creation is integrated in the Geometry::drawImplementation method. The 
compilation is delayed in the rendering traversal. For big VBOs, it 
causes frame drops because the everything that is in the render
graph is compiled.

It would be great if the VBO compilation can be decorrelated of the draw 
itself.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgViewer - embedded - slave cameras

[Lionel Lagarde]

Hi Robert,

Oh, ... Ok.

I'll look where the operations are added in the embedded mode.



Robert Osfield wrote:

Hi Loinel,

I'm not surprised that you need to call createSlaveCameras() before
the realize(), as the realize places the Operations required to do the
rendering for each camera on each GraphicsWindow, without these
Operations added no rendering will be done for these Cameras.

Robert.

On 7/27/07, Lionel Lagarde <[EMAIL PROTECTED]> wrote:

Hi,

I have some code that has to handle classic osgViewer::Viewer and
embedded osgViewer::Viewer.

We have also a predraw, a postdraw and a hud slave camera.

I'm trying to have almost the same code path in the 2 modes (embedded or
not).

For the moment, it looks like:

if (embedded)
{
   viewer.init();
   viewer.realize();
   createSlaveCameras();
}
else
{
   viewer.setUpViewAcrossAllScreens();
   createSlaveCameras();
   viewer.init();
   viewer.realize();
}

It's not so bad. It's just a few different lines but I don't understand
why the
embedded code path doesn't work in the non embedded case (The slave
camera are not
culled nor rendered).






___
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

[osg-users] osgViewer - embedded - slave cameras

[Lionel Lagarde]

Hi,

I have some code that has to handle classic osgViewer::Viewer and 
embedded osgViewer::Viewer.

We have also a predraw, a postdraw and a hud slave camera.

I'm trying to have almost the same code path in the 2 modes (embedded or 
not).

For the moment, it looks like:

if (embedded)
{
   viewer.init();
   viewer.realize();
   createSlaveCameras();
}
else
{
   viewer.setUpViewAcrossAllScreens();
   createSlaveCameras();
   viewer.init();
   viewer.realize();
}

It's not so bad. It's just a few different lines but I don't understand 
why the
embedded code path doesn't work in the non embedded case (The slave 
camera are not
culled nor rendered).






___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org