gmane.comp.graphics.openscenegraph.user

Re: Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

Judson Weissert — 2013-05-23T20:57:51

Thanks Robert.

I just realized that the modification to osgViewer::Viewer is not 
actually required to reproduce the problem in the osgviewer application 
since there are no update callbacks installed anyway. Originally, I 
could not get the behavior to happen in the unmodified osgviewer 
application, but I just tried again and the unmodified osgviewer 
application (when run with --run-on-demand dumptruck.osgt) did exhibit 
the problem after I played with it for a while.

Toggling the stats viewer while manipulating the model via right click 
and drag may increase the probability of triggering the behavior.

Sorry for my confusion,

Judson

On 5/23/2013 2:34 PM, Robert Osfield wrote:

Re: Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

Robert Osfield — 2013-05-23T18:34:35

Thanks for the code reproducing the problem, I'm just turning in for
the day so will have a look at trying to reproduce the issue tomorrow.

On 23 May 2013 18:32, Judson Weissert <judson-0RFHiqD3vBAAvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

Judson Weissert — 2013-05-23T17:32:47

Robert,

I figured out why my case diverges from the osgviewer application. I 
override osgViewer::Viewer::checkNeedToDoFrame(), member function, and 
call eventTraversal() on a code path where it would otherwise not be 
called. Specifically, I don't want the default behavior where a new 
frame is scheduled if the camera has an update callback, or the scene 
has update callbacks associated with it.

The attached patch contains a modification to 
osg/applications/osgviewer/osgviewer.cpp that exposes the problem I ran 
into. Notice that the checkNeedToDoFrame() implementation is exactly the 
same as it exists in osgViewer::Viewer except for the 3 lines that were 
removed via the #if 0 macro.

After applying the patch, I recompiled and ran:

osgviewer --run-on-demand --SingleThreaded --screen 1 spaceship.osgt

Throwing the model with the middle or right mouse button will 
occasionally cause the model to disappear. Granted, it does not 
reproduce every time. Right clicking and dragging horizontally seems to 
be

Re: How to apply textures to a model in openscenegraph?

Lokesh Kumar — 2013-05-23T17:33:52

http://www.junglee.com/mn/search/junglee/ref=nav_sb_noss?url=search-alias%3Dstripbooks&field-keywords=openscenegraph

Thank you Sergey Kurdakov,  

"Openscenegarph 3.0 cookbook" seems quite comprehensive.
so, i'm going for it.
 

really helpful.

-Lokesh

Re: How to apply textures to a model in openscenegraph?

michael kapelko — 2013-05-23T12:06:57

Totally agree on the OSG books. They are must-read.

2013/5/23 Sergey Kurdakov <sergey.forum-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

How to apply textures to a model in openscenegraph?

Sergey Kurdakov — 2013-05-23T11:58:37

Hi Lokesh

in http://www.packtpub.com/openscenegraph-3-0-beginners-guide/book on
support tab for the page of the book you may download sample code,

in \2824_12_Code\2824_12_Code folder from  download zip there is
sharing_textures.cpp which has a class

class ReadAndShareImageCallback : public osgDB::ReadFileCallback

you are looking for as example

make something similar, but before loading texture - change extension
of loaded image

I recommend to get existing osg books and read them - it will save you
a lot of time.
In India see http://www.junglee.com/mn/search/junglee/ref=nav_sb_noss?url=search-alias%3Dstripbooks&field-keywords=openscenegraph

Regards
Sergey

Re: How to apply textures to a model in openscenegraph?

Lokesh kumar — 2013-05-23T10:01:57



Thank you Robert!!

I'm interested in your 2nd alternative :- 

using osgDB::Registry::ReadFile      


but, i'm Newbie in openscenegraph.
can you give a short example.

Regards
-Lokesh

Re: How to apply textures to a model in openscenegraph?

Sebastian Messerschmidt — 2013-05-23T09:11:13

Hello Lokesh

A hack for testing would be to rename the references in the binary flt.
But this should be done for testing of course.

Another option is to run a visitor over the loaded model an replace the 
texture file name references with the new extension.

cheers
Sebastian

Re: How to apply textures to a model in openscenegraph?

Robert Osfield — 2013-05-23T08:49:39

Hi Lokesh,

The easist thing to do would be to use osgconv to convert the files to
native OSG binary format .osgb and have osgconv do the compression for
you.  Use osgconv --help for the options.  The other alternative to to
write your own osgDB::Registry::ReadFile callback that intercepts the
readImage calls and changes the filename to the .dds equivalent.

Robert.

On 23 May 2013 09:38, Lokesh kumar <Lokeshkumar.2010-24NTV5rpLUE< at >public.gmane.org> wrote:

Re: How to apply textures to a model in openscenegraph?

Lokesh kumar — 2013-05-23T08:38:59



Robert Osfield <robert.osfield< at >...> writes:



hi Robert,

I have a FLT model which has references to *.tga texture files(with proper
UV mapping).

i converted these *.tga files into *.dds texture files using Nvidia DDS
utility tool (nvdxt.exe).

now, i want to load and apply these *.dds texture files to my original FLT
model.


-Lokesh

Re: Problem when using DrawCallbacks with nested cameras

Robert Osfield — 2013-05-23T07:37:42

Hi Marcel,

The scheme to avoid rendering a camera multiple times in one frame
exists to avoid redundant passes being done.  I have to admit that
your setup is convoluted enough that I can't really follow it from a
quick read.   Given I don't understand your approach well enough I
can't pinpoint the best way forward.

In general I'd say that if you need multiple passes that each produce
a different output then you'll need multiple RTT Camera's rather than
one that is shared.  The way to manage this would be to have a custom
Node or cull callback that decides which of a set of RTT Camera to
traversal for each pass.  You can use do it without a cull
callback/custom node if you set up traversal masks for each pass so
that you can ensure that only the appropriate RTT Camera is traversed
for each pass.

Robert.


On 22 May 2013 19:41, Marcel Pursche
<marcel.pursche-oe7qfRrRQfelu5xYj6QLUmhqG95TSYEyhC4ANOJQIlc< at >public.gmane.org> wrote:

Re: How to apply textures to a model in openscenegraph?

Robert Osfield — 2013-05-23T07:32:38

Hi Lokesh,

Your OpenFlight model references all the textures it needs, and if you
want to replace or apply new ones you should simply reload the model
in Creator or other compatible modelling tool and apply the changes
you need then save again.

Robert.

On 23 May 2013 07:58, Lokesh Kumar <Lokeshkumar.2010-24NTV5rpLUE< at >public.gmane.org> wrote:

Re: Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

Robert Osfield — 2013-05-23T07:30:39

Hi Judson,

Great detective work. The change to the frame() was done to avoid
issues with events being given times that aren't in sequence -
previously we'd get time delta's that could be negative.

Do you have an idea of how to reproduce the problem now?  Once I can
reproduce it I'll be able to work out the best west to resolve the
problem.


Robert.

On 22 May 2013 22:50, Judson Weissert <judson-0RFHiqD3vBAAvxtiuMwx3w< at >public.gmane.org> wrote:

How to apply textures to a model in openscenegraph?

Lokesh Kumar — 2013-05-23T06:58:53

Hi,

I have a flt model and multiple *.dds texture files in a Directory :-

my folder contains :-

(1) terrain.flt
(2) road.dds 
(3) buildings.dds
(4) banners.dds

I know how to read and apply single  .dds texture file to my model 
(terrain.flt) :-

    osg::ref_ptr<osg::Node> terrainModel (osgDB::readNodeFile
("c:/my_folder/terrain.flt"));
    osg::ref_ptr<osg::Texture2D> tex (new osg::Texture2D);
    osg::ref_ptr<osg::Image> image (osgDB::readImageFile
("c:/my_folder/road.dds "));

    tex->setImage(image.get());
    
    osg::ref_ptr<osg::StateSet> state=terrainModel->getOrCreateStateSet(); 

    state->setTextureAttributeAndModes(0,tex.get
(),osg::StateAttribute::ON);



but i don't know how to read and apply all these textures to my model 
(terrain.flt).

Help me.

Re: Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

Judson Weissert — 2013-05-22T21:50:10

Robert,

I found the revision that caused the regression. Ironically, it occurred 
way before the 3.1.6 release...

See r13092 associated with 
http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk/src/osgViewer/Viewer.cpp

The 3.1.2 behavior returned when I reverted that revision. A notable 
behavior change that I noticed is that before I reverted r13092, the 
OSG_INFO<<"Reset event time from ..." line in EventQueue::takeEvents() 
would trigger extremely often (e.g., while hovering over the viewer 
window). It does not trigger at all after I reverted r13092.

See also the cutOffTime variable in Viewer::eventTraversal() which 
explains the link to ON_DEMAND frame scheduling.

Do you happen to know the original intention of r13092? The log message 
is "Moved the frame() event into the event traversal after then events 
and their state have been accumulated."

Thanks for the help,

Judson


On 5/22/2013 3:02 PM, Judson Weissert wrote:

Re: File comment blocks conflict with OSGPL licensing, geo plugin

Robert Osfield — 2013-05-22T19:55:41

Hi David,

I'm inclined to think it's safe to remove it as it's for a defunct product
and likely to mostly out of use now.

Licensing side is a bit murky, the intent for sure was that it was to be
open sourced, and made open source in full knowledge and support of Carbon
Graphics so it's really just a case of not dotting all the i's and crossing
all the t's. Since Carbon Graphics is no longer around we'd need to talk to
the original company owner/author. Anyone still in contact with him? The
chance of anyone actually being taken to court by someone who buys up the
rights to Carbon Graphics is pretty slim, and given the original intent was
to open source it they'd have little to stand upon in court. I think this
risk is close to zero, it's basically hypothetical.

Code maintenance wise the effort level is close to zero.

Overall I'd say that if no one is using it then there is little reason to
have it, and given there is lack of clarity on licensing there is no

Robert.

On 22 May 2013 15:38, David Fries <Dav

Re: Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

Judson Weissert — 2013-05-22T19:02:20

Robert,

I have made some progress. The problem appears to be caused by an 
eventTimeDelta of zero which is calculated within 
StandardManipulator::performMovement(). It eventually results in a 
divide by zero and the propagation of non-finite value(s) through the 
remainder of the call chain. Specifically, dy in 
OrbitManipulator::zoomModel() and OrbitManipulator::panModel() ends up 
being a non-finite value.

Thus, I have found an explanation for the symptoms, but I have not 
tracked down the underlying cause of eventTimeDelta being calculated as 
zero. Therefore, I have not been able to create a small example case yet.

Regards,

Judson

On 5/22/2013 2:37 PM, Robert Osfield wrote:

Re: Problem when using DrawCallbacks with nested cameras

Marcel Pursche — 2013-05-22T18:41:36

Hi,

I found the cause of the problem myself. When the scene graph is traversed a osgUtil::RenderStage is created for the camera and added to the RenderCache of the camera. So only one RenderStage per CullVisitor is created. When the RenderStage is drawn it sets a flag that is was already drawn this frame.
So no matter how often you add a camere to the scene graph, it's scene is only rendered once. This optimization makes sence in most cases, but in my special case it would be great if I could turn it off.

I currently have two solutions for this problem:

1. A PostDrawCallback that resets the RenderStage flag by accessing the RenderCache of the current camera. This solution is extremly ugly. I had to copy the interal osg class osgUtil::RenderingCache because it is in no header file. A very bad hack: If the code of this class changes or the compiler creates a different memory layout(different optimizations turned on etc.) the dynamic_cast from osg::Object to osgUtil::RenderingCache can go terribly wrong.

2.

Re: Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

Robert Osfield — 2013-05-22T18:37:36

Hi Judson,

It's a curious set of circumstances but as yet I can't think of a
specific cause.

Is there any chance you can create a small example that illustrates
the problem so that I can try it out and see if I can spot the
problems.

Cheers,
Robert.

On 22 May 2013 18:31, Judson Weissert <judson-0RFHiqD3vBAAvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

Judson Weissert — 2013-05-22T17:31:57

Robert,

The viewer I am running has ON_DEMAND frame updates. When I remove the line

viewer->setRunFrameScheme (osgViewer::ViewerBase::ON_DEMAND);

the disappearing geometry behavior goes away. However, I was not able to 
replicate the problem by applying ON_DEMAND frame updating to the 
osgviewer application.

Thus, there is still a piece of the puzzle that I am missing.

Regards,

Judson

On 5/22/2013 12:10 PM, Judson Weissert wrote:

Problem when using DrawCallbacks with nested cameras

Marcel Pursche — 2013-05-22T16:31:01

Hi,

I'm currently having a problem in understanding, when the PreDrawCallback and PostDrawCallback of a camera are called. I'm working on a project where Virtual Texturing and Depth Peeling is used.

For Virtual Texturing the following steps are necessary:
1. Render whole scene with special texture id shader to a texture
2. Call PostDrawCallback that reads this texture and creates a list of all necessary texture ids
3. Call PreDrawCallback that loads all necessary textures
4. Render scene with virtual texturing shader

Depth Peeling is done in the following way:
1. Render opaque geometry to textures(color and depth buffer)
2. Render transparent geometry to textures(color and depth buffer), discard fragments that have a higher depth, than the opaque geometry
3. Render transparent geometry to textures(color and depth buffer), discard fragments that have a higher depth, than the opaque geometry, or a lower depth, than the last transparent pass
4. repeat 3 for each peeling pass
5. Combine opaque and transparent