[osg-users] PagedLOD preprocessing

Hi, advanced problem: Is there a chance to preprocess scene by OSG to use PagedLOD? The scene contains 3GB of textures (or any higher number). My idea was to make PagedLOD scene that would load high-resolution textures only for the most close scene parts to the camera. The problem is clear:

Re: [osg-users] PagedLOD preprocessing

The scene contains 3GB of textures (or any higher number). My idea was to make PagedLOD scene that would load high-resolution textures only for the most close scene parts to the camera. 3GB is not overly large, and the reason for PageLOD existance is helping handle this and much large

Re: [osg-users] PagedLOD preprocessing

Paul Martz napsal(a): [...] The naïve approach -- just let OSG load it -- appears to cause a guaranteed frame rate hit. I imagine you could break the texture up into smaller chunks and let OSG page each in incrementally as it comes into range. Yes, breaking the texture into the smaller ones

[osg-users] CMake problem

variables. John PCJohn napsal(a): Hi, this is probably question on Luigi: Inventor plugin CMakeLists.txt stopped working - it is neither including necessary includes correctly detected by FindInventor.cmake, nor linking libraries correctly detected in the same way. Therefore, the plugin

Re: [osg-users] Please test SVN version of OpenSceneGraph

How are others under WIndows getting on? Except linking problem of osgversion, just few warnings. On MSVC 2003 .NET: In osg: Texture2DArray.cpp \OSG\src\osg\Texture2DArray.cpp(106) : warning C4018: '=' : signed/unsigned mismatch D:\OSG\include\osg\Math(197) : warning C4244: 'return' :

Re: [osg-users] Benchmarking Software (Linux)

If you are looking for things like 3D mark 2006, I do not know. But for a very simple benchmark measuring basic OpenGL characteristics like vertices per second throughput and pixels per second (fillrate), you may take a look on lsperf.sourceforge.net . (No binaries yet, sources in svn: |svn co

[osg-users] multiple osgShadow::ShadowMap

Hi, Is it possible to have multiple shadow maps? I mean, f.ex., two light sources and two osgShadow::ShadowMap casting two shadows in a single pass? Studying osgShadow::ShadowMap shows that it is not directly supported. Anyway, I created two ShadowMaps, made one parent of the other and a

Re: [osg-users] Questions about physic engines.

Hi Ricardo, sorry to not go into the details - so just few hints from my friend that is going his project on ODE+OSG. He done the integration like this: - he loads the scene by OSG - he converts the scene geometry to ODE geometry and sends it to ODE by ODE functions - he setups the ODE world

Re: [osg-users] 2.8.3 release likely, need community assistance

Is it possible to include plugins? I am particularly interested in updated Inventor plugin. John Paul Martz wrote: Hi folks -- I am 99% certain that I'll be doing a 2.8.3 release in the next few weeks. The release will not be API compatible with 2.8.2. I wanted to let you all know my plans,

Re: [osg-users] 2.8.3 release likely, need community assistance

. John Paul Martz wrote: PCJohn wrote: Is it possible to include plugins? I am particularly interested in updated Inventor plugin. John Hi John -- I've merged the latest Inventor plugin onto the 2.8 branch. Can you test, please? I don't have the dependencies, so don't build this plugin. -Paul

Re: [osg-users] [osgPlugins] iv plugin with coin4 from svn

j...@dudell:/data$ osgviewerd cube.iv osgDB::ReaderWriterIV::readNode() Reading file cube.iv osgDB::ReaderWriterIV::readNode() File cube.iv loaded successfully. j...@dudell:/data$ I see no problem with the model - it is loads and renders without any problem on my OSG 2.8.2 and Coin 3 John

[osg-users] light multi-parenting

Hi, I reached some difficulties with handling of lights when I was considering some improvements to osgShadow, like multiple light sources: 1. single light source object can be placed two times to the scene. Because of multi-parenting, the light may have two different transformations.

Re: [osg-users] light multi-parenting

Hi J-S, 1. single light source object can be placed two times to the scene. Because of multi-parenting, the light may have two different transformations. Although one object and one unique pointer, it identifies two light sources, thus it is not unique light identification. How do you give a

Re: [osg-users] light multi-parenting

Hi Bryan, osg::Light is a StateAttribute and osg::LightSource is a Group, so Light represents the OpenGL state (like the light ID) for a light in the scene, and LightSource represents the location of that light (note that LightSource has a Light). And why there is LightSource? What is

Re: [osg-users] light multi-parenting

Gurus, What is the reason for keeping LightSource in OSG? I successfully removed all osg::LightSources from my scene graph and used just osg::Light - it is well placed and follows the transformation of the parent node (f.ex. locomotive) as it moves. Except absolute reference frame, is there

Re: [osg-users] light multi-parenting

inherited, so LightSource's role is to place the light. Robert. On Mon, Mar 22, 2010 at 11:52 AM, PCJohn pec...@fit.vutbr.cz wrote: Gurus, What is the reason for keeping LightSource in OSG? I successfully removed all osg::LightSources from my scene graph and used just osg::Light

Re: [osg-users] light multi-parenting

As for limitation osg::Light/LightSource/OpenGL lighting all work with the same limitations - that is there is only ever guaranteed to be 8 fixed function pipeline light supported. If you want to use more than 8 then you'll need to use shaders, or localize the lights to difference subgraphs

Re: [osg-users] About OSG and Distributed Issue?

Hi Dolin, the complexity of distributed/collaborative virtual scenes are so high that you can make a PhD research on it. You can google for Blue-c, DIS (Distributed Interactive Simulation), Active Transactions, etc. for more details. Basically, the problem is coming from the replication - you

Re: [osg-users] About OSG and Distributed Issue?

Interactive Simulation, is it feasible? Donlin 在2010-04-16 03:35:23，PCJohn pec...@fit.vutbr.cz 写道： Hi Dolin, the complexity of distributed/collaborative virtual scenes are so high that you can make a PhD research on it. You can google for Blue-c, DIS (Distributed Interactive

[osg-users] getCameraContainingPosition in osg::View

Hi, why are methods: computeIntersections and getCameraContainingPosition implemented in osgViewer::View class? I wish it would be in osg::View. Any chance? If yes, I may contribute one more feature for osgGA camera manipulators. I am in the process of osgGA camera manipulators improvements:

Re: [osg-users] RFC: QWidgetImage changes

Hi J-S, thanks for the work. I am going to test it soon. John Jean-Sébastien Guay wrote: Hi all, As I said in a different thread, I've been working in the last few days to get QWidgetImage to a point where it can fill a need we have: to be able to use Qt to make HUDs and to display widgets

Re: [osg-users] Manipulator warning: eventTimeDelta =

Hello, it used to be INFO, so it might not be so visible before. It is caused by an event that comes with lower timestamp than the previous one, e.g. event from the past. For me, it looks like a bug in event time routines. John Torben Dannhauer wrote: Hi, after upgrading my osg to newest

[osg-users] osgQt broken in OSG trunk

Just reporting a compile problem in OSG trunk in osgQt. See compiler output bellow. The problem was noticed on Qt 4.4.0. While it is not present on some more recent Qt versions. Probably broken compatibility with older Qt. John Scanning dependencies of target osgQt [ 98%] Building CXX object

Re: [osg-users] osgQt broken in OSG trunk

, PCJohn pec...@fit.vutbr.cz wrote: Just reporting a compile problem in OSG trunk in osgQt. See compiler output bellow. The problem was noticed on Qt 4.4.0. While it is not present on some more recent Qt versions. Probably broken compatibility with older Qt. John Scanning dependencies of target

Re: [osg-users] old QOSGWidget and new trunk Manipulators : mouse event problem

Hi Eric, if the behavior is the same for all manipulators, it means that it has nothing to do with new manipulators architecture. For example, SphericalManipulator is still using the old approach. If you see the problem even with this manipulator, the bug seems likely to be on some other

Re: [osg-users] different behavior on the trackball manipulator

Hi Nick, there are two major changes to CameraManipulator::computeHomePosition(): - the computation uses bounding box by default (the model center is located more precisely) - the computation considers the camera fov to make sure that the model nicely fits to the screen (small fov may make the

Re: [osg-users] different behavior on the trackball manipulator

Hi JP, the zoom update submission was sent to Robert and it waits for commit. It reverts the zoom to use original behaviour by default. Concerning 4 manipulator, which one do you mean? I am expecting it is TerrainManipulator. It avoids you to go over +/- 90 degrees in vertical direction. It

Re: [osg-users] different behavior on the trackball manipulator

John, I just ran an old code. In the older version, the model was centered on the screen. with the new manipulators it is not. I use the default behavior -Nick On Sat, Jun 12, 2010 at 2:28 PM, PCJohn pec...@fit.vutbr.cz mailto:pec...@fit.vutbr.cz wrote: Hi Nick, there are two

Re: [osg-users] different behavior on the trackball manipulator

Send me the code if you want. I will take a look. If the size of data would be larger, use my email address only. Thx, John Trajce (Nick) Nikolov wrote: it is using some sample with osgviewer., I can post you the code if you are interested. -Nick On Sat, Jun 12, 2010 at 2:53 PM, PCJohn pec

Re: [osg-users] osgGA::CameraViewSwitchManipulator

[..] As with in so many areas of OSG, the main documentation is the source code. My big wish would be to change this and to require submissions to contain documentation as well. Mandatory doc requirement would be probably too much, but at least official desire for documentation should be

Re: [osg-users] current context

Thanks. I was worrying about such answer, but that is logical design. I will probably proceed with drawCallbacks and make scene graph updates in update event. Thanks, John Tim Moore wrote: On Sat, Jun 19, 2010 at 7:29 AM, PCJohn pec...@fit.vutbr.cz mailto:pec...@fit.vutbr.cz wrote

Re: [osg-users] [osg-submissions] Shader composition

Hi Robert, I would appreciate others having a look at Roland's implementation as well. I took a look at Rolands code some time ago as I built my own simple shader composition for myself as well. The problems, I found myself with shader composition is that I often need to customize the

Re: [osg-users] FirstPersonManipulator

Hi Julien, just to avoid misunderstanding: Manipulator, you are speaking about, is not the one submitted to trunk short time ago, but the one downloaded from internet, probably. John Julien Soula wrote: Hi, Is this manipulator still on tests ? I just tried it and had the same You are

[osg-users] setAmbientIntensity without setTwoSided

Hi, I want to set ambientIntensity. There is a class for it - osg::LightModel. However, I do not want to do anything with TwoSided, LocalViewer or ControlColor settings. They must be inherited from the state above in the scene graph. How to achieve that? Thx, John

[osg-users] threading and captureCurrentState

Hi, I see a threading issue when capturing current attributes in cull phase. My code placed in my derived ShadowTechnique::cull(): void MyShadowVolume::cull( osgUtil::CullVisitor cv ) { ref_ptr StateSet currentState = new StateSet; cv.getState()-captureCurrentState( *currentState );

Re: [osg-users] threading and captureCurrentState

to be valid in Render stage. SingleThreaded mode is bit different and manages SceneViews differently which has the side effect that OpenGL context often remains valid beetwen Render stages . Wojtek -- From: PCJohn pec...@fit.vutbr.cz Sent

Re: [osg-users] threading and captureCurrentState

Hi Tim, Tim Moore wrote: On Wed, Aug 4, 2010 at 9:33 AM, PCJohn pec...@fit.vutbr.cz mailto:pec...@fit.vutbr.cz wrote: Hi, captureCurrentState name is misleading - it is not capturing state from OpenGL. It should be, maybe, getCurrentState. It is just taking last pushed

Re: [osg-users] threading and captureCurrentState

Yes. There is. Oh. I see. Sorry for confusion, you call it attribute stack and that is a correct name for it. Anyway, there is State::_attributeMap that is composed of AttributeStack structs and they have a member attributeVec that is serving as a stack of attributes.

Re: [osg-users] threading and captureCurrentState

gl_FrontFacing variable could do the trick ? Its available at least in GLSL 1.50 and above. I have not checked when it was introduced maybe its available in earlier GLSL profiles. Wojtek *From:* PCJohn mailto:pec...@fit.vutbr.cz *Sent:* Thursday, August 05, 2010 12:41 AM *To:* OpenSceneGraph Users

[osg-users] precompiled binaries

Hi, I want to contribute precompiled binaries of Inventor/Coin plugin to https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs80sp1 and https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs90sp1 . Is there a

[osg-users] time going backward

Hi, I see events coming with decreasing time (GUIEventAdapter::getTime()). However, I expected always increasing sequence. Is this feature or bug? Further investigation shows that current OSG trunk sends different timestamps for FRAME events than for other events. Seems like it is using

[osg-users] shared context and compile context

I have fallen to the problems of compile context and sharing lists (wglShareLists, glXCreateContext(x,x,true,x)). They share display lists, VBO/IBO, shaders, textures, FBO, PBO. But how is it with rendering capabilities, e.g. is OSG compile context and shared OpenGL context guaranteed to have

Re: [osg-users] shared context and compile context

app and the platforms that your are targeting then great, but otherwise I'd suggest not trying to use them. Robert. On Wed, Oct 6, 2010 at 1:04 PM, PCJohn pec...@fit.vutbr.cz wrote: I have fallen to the problems of compile context and sharing lists (wglShareLists, glXCreateContext(x,x,true,x

Re: [osg-users] shared context and compile context

Thanks. Very answered my question. John Robert Osfield wrote: Hi John, On Wed, Oct 6, 2010 at 1:45 PM, PCJohn pec...@fit.vutbr.cz wrote: I see, sharing context is not so portable... I implemented them under Linux with NVidia drivers and they worked as expected, but with other

[osg-users] Shadow Volumes integration

Hi, me and my coleague have developed number of Shadow Volume shadow algorithms and we would like to contribute them one day to OSG. To mention the reason for Shadow Volumes: They are often used in CAD, etc. as they work in screen space, thus they do not suffer with aliasing/resolution

Re: [osg-users] Shadow Volumes integration

, PCJohn wrote: Hi, me and my coleague have developed number of Shadow Volume shadow algorithms and we would like to contribute them one day to OSG. To mention the reason for Shadow Volumes: They are often used in CAD, etc. as they work in screen space, thus they do not suffer

[osg-users] LineSegmentIntersector numerical imprecisions

Hi Robert, there was recently a commit concerning epsilon in LineSegmentIntersector that is now carried as class member. I can imagine motivation behind, but I belive there is a better approach to the problem. If the motivation is just to allow the setting bigger epsilon for bigger objects

Re: [osg-users] LineSegmentIntersector numerical imprecisions

and the range of the numerical errors that are likely. The largest value is likely to be the length of the line segment so might be the best distance to use as the scale. Thoughts?Robert. On 19 August 2013 06:38, PCJohn pec...@fit.vutbr.cz[1] wrote: Hi Robert, there was recently a commit

Re: [osg-users] LineSegmentIntersector numerical imprecisions

Hi Robert, I have lost in your reasoning. Let me go back to be sure we understand each other. The bounding box based epsilon will likely fail when the size of the box is very small compared to the length of the line segment. I came to conclusion that size of bounding box does not matter.

Re: [osg-users] LineSegmentIntersector numerical imprecisions

if()else blocks that are relatively expensive for the processor to handle. Robert. On 20 August 2013 10:33, PCJohn pec...@fit.vutbr.cz wrote: Hi Robert, I have lost in your reasoning. Let me go back to be sure we understand each other. The bounding box based epsilon will likely

Re: [osg-users] LineSegmentIntersector numerical imprecisions

Hi Robert, after this new idea, I am starting to ask myself, what are the cases for which we need epsilon? - when the line segment accidentally misses bbox while triangle intersection routines would indicate intersection (can this happen?) - when clipping puts the start or end point inside the

[osg-users] graphics context capabilities in cull phase

Hi Robert, I noticed one missing feature in OSG and I would be glad to discuss the solution with you before making further steps. The problem: - In cull phase, it would be useful to be able to find out which OpenGL extensions are supported and GLSL version available in the graphics context.

Re: [osg-users] graphics context capabilities in cull phase

all extensions even the ones that you application doesn't need. Robert. On 19 September 2013 14:43, PCJohn pec...@fit.vutbr.cz wrote: Hi Robert, I noticed one missing feature in OSG and I would be glad to discuss the solution with you before making further steps. The problem

Re: [osg-users] graphics context capabilities in cull phase

Hi Robert and Mathias, back after the weekend. I do also wonder about formalizing the extension set up. In essence we are initializing bool relating to feature supported yes/no, and the function pointers. Currently it's all rather adhoc how this is all done. The whole area could do with a

Re: [osg-users] How change the vertical sync?

Hi Julio, this is the code I am using (you may need to reformat it, because email splits many lines into two). Call it once you have active context. You may still need some includes like #include osg/GLExtensions #if defined(__WIN32__) || defined(_WIN32) # [...] #else # include GL/glx.h #endif

[osg-users] osgt - kate syntax highlight

Hi all, I wanted to hand-edit osgt files. It is nightmare to do it without code- folding and text highlighting. Thus, I created highlight definition file for kate editor (attached). Especially, code folding is very very helpful to edit and analyse any osgt file. For those interested: To

[osg-users] Camera callbacks

Hi, I very like the capability of osg::Node to register any number of update, event and cull callbacks. This allows for a nice modular approach with each module registering callbacks for anything they wish without disturbing others. I came to a problem that Camera can register just one

Re: [osg-users] Camera callbacks

, but it'd keep the public Camera API simple - it's complicated enough as it is so am reluctant to add further API to it. The alternative would be to add a list of callbacks, but as you said this would break compatibility. Robert. On 9 April 2014 14:10, PCJohn pec...@fit.vutbr.cz wrote: Hi

[osg-users] ProxyNodes

Hi, I want to load my scene from multiple files. There should be one main.osgt file that should include or reference other files. I was expecting that osg::ProxyNode should serve for this purpose. Or is there another friendly approach? ProxyNode difficultly: - it does not support immediate

[osg-users] Uniform above Program

Hi, it seems that it is not possible to put an uniform to the stateset of the scene root (for example, light position) and to put Program at the bottom (say, at a stateset of a drawable). It seems to me that the Program and all its Uniforms must be put the same StateSet. This way, it works

Re: [osg-users] Uniform above Program

not true, and works for me all the time. Can you post minimal example that dont work? Cheers, Sergey. 17.08.2012, 12:20, PCJohn pec...@fit.vutbr.cz: Hi, it seems that it is not possible to put an uniform to the stateset of the scene root (for example, light position) and to put Program