Re: [osg-users] Off topic question and request for ideas

[werner.modenb...@texion.eu]

Hi Chris,
it is just the surface and borderlines rendering with the filaments. No 
dynamics.

On 14. Dezember 2018 21:51:48 MEZ, Chris Hanson  wrote:
>Are you talking about the rendering aspect or the cloth dynamics
>simulation
>aspect?
>
>On Fri, Dec 14, 2018 at 3:35 PM Werner Modenbach
>
>wrote:
>
>> Hi all,
>>
>> first of all I apologize for an off topic question.
>> I spent weeks already in the Internet for finding a solution for a
>> problem - without success.
>> And I know there are a lot of experienced people here in the list.
>>
>> I'm doing high quality simulations of textiles from machine data. So
>I
>> have to
>> simulate each yarn as realistic as possible. This works perfect if
>the
>> yarn is not hairy.
>> That means it has no filaments pinning out of the surface i.e. like
>wool.
>> The only approaches I found so far are here:
>>
>https://www.shadertoy.com/results?query=fur=popular=0=12
>>
>https://developer.nvidia.com/gpugems/GPUGems2/gpugems2_chapter01.html
>> Both of them have big cons for my requirements.
>>
>> Is anybody here having hints or ideas for solving this problem?
>>
>> Sorry for this off topic message. Please answer to my PM in order not
>to
>> spam to much to the list.
>>
>> Many thanks for any help
>>
>> - Werner -
>>
>>
>> ___
>> osg-users mailing list
>> 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  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] osgQt + OSG 3.6.2 Status

[werner.modenb...@texion.eu]

Hi Joshua,
I fully agree with you. We are developing commercial software and started with 
plenty of years ago. About 10 years ago we started to use osg and embedded osg 
view into a qt widget based on the osg-qt project at that time. It worked 
smoothly since then. Now we are on the latest releases of osg and qt and we 
never had to touch our embedding class. The only thing I am missing is the 
compatibility of threading. But we can live with that and I'm not limited in 
threading inside qt.
Qt is great for development of cross platform user interfaces and frees me of 
Microsoft related usage of system interfaces. During all those many years there 
were only 2 cases where something didn't work as expected. But we could debug 
and fix it due to open source.
So we are happy with the combination of qt and osg. Both are reliable, stable 
and have excellent features in their field. 
Werner

On 27. Juli 2018 19:19:17 MESZ, Joshua Tree  wrote:
>I have to chip in here. Qt is the most reliable, industry standard UI
>for C++,  period. In part this success is due to the moc
>autogeneration, which could get you out of SFINAE madness.
>
>Now, there are huge firms that adopted Qt for decades and run multi
>billion dollars systems on it. 
>
>That said, the Qt source is online and you can modify it as you wish to
>test a solution. It is puzzling to me how this is still a pending and
>recurrent issue for over a decade and a half I follow OSG.
>
>
> I have used Qt and OSG back in 2003, 15 years ago with success. 
>
>> On Jul 27, 2018, at 12:03 PM, Robert Osfield
> wrote:
>> 
>> Hi Andrew,
>> 
>>> On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham 
>wrote:
>>> I would agree QT is not perfect but on the flip-side
>>> - It is the 'last man standing' of x-platform UI's.
>> 
>> This is down to the weakness of the alternatives rather as much as
>the
>> strength of Qt.
>> 
>>> - It's actively developed using the latest C++11/14 standards and
>supported by both a commercial organization and a robust LGPL community
>> 
>> Will they get rid of the non standard C++ extensions and
>pre-compiling nonsense?
>> 
>>> - Is has a new lease of life through PyQT5 and PySide being the
>'de-facto' way to build Python based desktop UI's.
>>> - QML is quite interesting
>> 
>> There is simply too much pushed into Qt over the years. The lack of
>> focus on the core functionality hurts it.
>> 
>> I say this from experience, we've pushed too much functionality into
>> the OpenSceneGraph distribution over the years, I can see the
>> mistakes, but with backwards compatibility being an important factor
>> for end users it's not easy to just make radical changes.
>> 
>> What the computer industry is a nice neat, small C++11 UI library
>with
>> good hooks to building scripting integration on top of.
>> 
>>> I don't know why QT and OSG seem to fight each other so much, but it
>seems a PITA to get things working properly as the OP and I have both
>found mysterious issues popping up that require trips into the debugger
>and the QT and OSG source. I had to advocate for OSG as other
>developers were keen to use QT3D instead.
>> 
>> OSG integration with 3rd party windowing toolkits has generally been
>> pretty straight forward - once the basics have been written it
>doesn't
>> take much to update and keep things working.
>> 
>> Our experience with Qt is not like this at all.  X11, Win32 they've
>> been pretty rock solid for way over a decade now.  OSX has required
>> jumping through a hoops because Apple doesn't care about developers
>as
>> much as it cares about vendor lock-in.
>> 
>> Over the years the OSG hasn't added extra burden on the 3rd party
>> windowing toolkits, it's exactly the same as it has always been, just
>> create a GL context and allow the OSG to call makeCurrent() and
>> swapBuffers and we are pretty well done.  It *should* be simple.  It
>> is requires is the 3rd party windowing toolkit not to screw around
>> with things. It's Qt screwing around with things that is breaking
>> things, they have lost sight of what the Windowing API should be
>doing
>> and trading on the toes of application develop codes/3rd party SDK's
>> like the OSG.
>> 
>> Qt *is* broken in this respect. It really should be down to the Qt
>> support to help you work out how to fix this.
>> 
>> --
>> 
>> It terms of thinking about migrating away from OpenSceneGraph to
>Qt3D,
>> this might solve the Qt integration issue, but it just further
>cements
>> the lock-in to Qt, you'll end up tied to their future success or
>> failures.
>> 
>> The future of scene graphs isn't OpenGL/OpenGL ES, it's Vulkan, so if
>> you really want to migrate to another scene graph then it should be
>> Vulkan based if you want it to be future proofed.  Qt3D might be
>> ported to Vulkan, but it'll still be tied to Qt and all the baggage
>> that goes with it.
>> 
>> Modern computing should be based around well designed and
>> functionality focused components that can be mixed and matched as to
>> the 

Re: [osg-users] Culling and instanced drawing

[werner.modenb...@texion.eu]

Thanks. Any suggestion how to know this?

On 13. Juli 2018 21:27:30 MESZ, Julien Valentin  
wrote:
>Indeed...
>
>wernerM wrote:
>> B.T.W. Is there any way of doing the culling in Tesselation- or
>> Geometry-Shader?
>> In this case I need to know if the vertices are visible or not.
>> 
>> Am 13.07.2018 um 18:51 schrieb Robert Osfield:
>> 
>> > Hi Werner,
>> > 
>> > The best way to handle the vertex shader moving geometry to new
>> > locations is to use a custom
>osg::DrawableComputeBoundingBoxCallback
>> > that you assign the the drawable that you are using for instancing.
>> > You'll want to return a BoundingBox that encompasses all the
>positions
>> > that the transformed geometries can occupy.
>> > 
>> > Robert.
>> > On Fri, 13 Jul 2018 at 17:44, Werner Modenbach
>> > <> wrote:
>> > 
>> > > Hi all,
>> > > 
>> > > maybe someone has some inspiration for me.
>> > > I have a scene graph where the same object (plenty of vertices)
>is drawn
>> > > in many instances.
>> > > Each instance gets an offset matrix to move the object to some
>place.
>> > > If I do the rendering without instances the culling removes those
>> > > objects from the draw list that are not visible.
>> > > Is there any way to implement such culling also with instances?
>> > > I think I need to remove the invisible matrices from the list and
>reduce
>> > > the number of instances somehow.
>> > > 
>> > > Any idea where to do it?
>> > > 
>> > > Thanks
>> > > 
>> > > - Werner -
>> > > 
>> > > 
>> > > ___
>> > > osg-users mailing list
>> > > 
>> > >
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> > > 
>> > ___
>> > osg-users mailing list
>> > 
>> >
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> > 
>> 
>> 
>> ___
>> osg-users mailing list
>> 
>>
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> 
>>  --
>> Post generated by Mail2Forum
>
>
>
>Twirling twirling twirling toward freedom
>
>--
>Read this topic online here:
>http://forum.openscenegraph.org/viewtopic.php?p=74342#74342
>
>
>
>
>
>___
>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] Draw geometry on demand

[werner.modenb...@texion.eu]

Hi Tyler,
if you set a new vertex array or change an existing on in a drawable of the 
scene graph it should show the changes in the next render frame. There is no 
need for doing something special. Maybe you have to set the modified array 
sorry. That's all.

On 10. Juni 2018 09:53:34 MESZ, Tyler Durden  wrote:
>Hi,
>
>I like to know how to redraw geometry on demand.
>I have a osg:geometry with attached VertexArray and PrimitiveSet.
>I need to send draw command to redraw geometry.
>I see there is a "draw" method in DrawElements class, but that wants 
>an osg::State that i dont know how to get. 
>Or alternatively is there any other procedure how to do that, like some
>UpdateCallback?
>Can anyone help me?
>
>Thank you!
>
>Cheers,
>Tyler
>
>--
>Read this topic online here:
>http://forum.openscenegraph.org/viewtopic.php?p=74018#74018
>
>
>
>
>
>___
>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] When gets the view matrix of a camera ipdated

[werner.modenb...@texion.eu]

Hi all,
I have written some classes for special effects like ambient occlusion or 
shadow.
All those classes are using their own prerender cameras. The cameras use the 
initial draw callback for updating their view matrices by using the main 
cameras view matrix.
Unfortunately it looks like the rendered shadow/ ambient occlusion matrices 
correspond to the previous frame. So my guess is that the view matrix of the 
main camera isn't updated from the camera manipulator at the time of the 
callback.
Is there any better callback I can use for that?___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Improving performances

[werner.modenb...@texion.eu]

Hi Alex,
I'm doing simulations of textile structures and work with yarn objects being 
deformed according to Bentsen stretches etc.
The number of triangles is also extreme. I have a COUPLE bound version doing 
the geometries by CPU threads and a second version working with geometry 
shades. Both versions have their pros and cons. But performance wise the second 
version is far the best - at least with a very good graphics card. 
I think the biggest advantage is the dramatically reduced amount of data to be 
transferred. This results in immediate appearance on the screen and reduced 
processing time for culling etc.
Also with vertex parameters I can control the geometry shades. In this case 
vertices are just center line polygon points.
May be this helps you in finding your best approach. 
Werner

On 15. Februar 2017 16:03:12 MEZ, Ale Maro  wrote:
>Hi,
>
>I posted some question about OSG performance in the past and now I
>would like to definitively improve visualization performance of my
>application.
>I want to say that now I already have very good performances with OSG
>but now I need to start thinking how to manage also some "extreme"
>scenes.
>
>It is a CAD-like application and a possible scene is composed by some
>objects (let's say from 1 to some hundreds) each one with 100K to some
>millions of triangles. 
>Each of these objects can have up to some thousands of children each
>one with around 100 triangles.
>For all objects I use vertexbuffer instead of display lists to reduce
>waiting time at first draw (due to display list compilation).
>I use a matrixtransform for each object and few groups for all the
>scene.
>Normally objects are not modified but sometimes they can be modified on
>the fly by user. So I did not set DataVariance (I supposed it is set
>automatically to STATIC if I did not modify an object).
>The application is GPU bounded as I can see from on-screen stats.
>
>I cannot merge objects or groups into one becouse I need to do some
>operations on them so I need to keep them separated.
>I am using KdTrees to improve object picking, it now works well but the
>interaction is still not smooth becouse of the slow frame rate.
>I think I cannot use LODs becouse triangle reduction on-the-fly can
>take very long time on this type of scenes.
>I tried with osgViewer and more or less it have the same performance of
>my application.
>At the moment I can just show bounding boxes for raw scene manipulation
>but often I need to show object details.
>
>Could you give me some hint to improve performances? I hope information
>I give you are enough to do a first analysis.
>At the moment I am not able to setup such a scene to send you
>screenshots of the stats but I can do it in next days if needed.
>
>Thank you in advance.
>
>Best regards,
>Ale
>
>--
>Read this topic online here:
>http://forum.openscenegraph.org/viewtopic.php?p=70200#70200
>
>
>
>
>
>___
>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] Detecting when a texture is to big for graphics memory

[werner.modenb...@texion.eu]

Hi Allister,
I have a comparable situation  in my software. Displaying huge textures.
I got help from the list recently and now it works like a charm.
I split the texture in small tiles and assign them to textured quads. The quads 
are arranged to form a huge plane. The trick is arranging them in a PagedLOD 
Structure as a quad tree. Always 4 tiles create a tile of the same size in the 
next distance level with lower resolution. The tiles are loaded dynamically on 
whatever distance they appear. This way the total load of textures is not so 
high and manageable by the hardware.
Send me a private mail if you need more details. 
Werner

On 30. November 2016 15:42:17 MEZ, Alistair Baxter  wrote:
>Our application is using osgVolume to render 3D texture data that is
>provided by users. This means the data can be very large, and can
>exceed the amount of available graphics memory on some machines.
>
>I was looking for a way to detect whether a texture has failed to load
>in this way, so that we can alert the user, or react to the problem in
>some other way. But I'm having trouble finding anything in code that
>will help.
>OpenSceneGraph responds with   "Warning: detected OpenGL error 'out of
>memory' at after RenderBin::draw(..)"   but I'm not seeing anything in
>the scene graph data that can indicate that the texture in question is
>at fault. The TextureObject representing the 3D texture, for example
>declares that it is allocated, and reports the correct size and a
>positive id.
>
>Is there any way to tell whether a texture is too big for graphics
>memory, other than by just knowing how much there is in total  (a
>feature that only seems to work for me on NVidia hardware anyway) and
>checking whether the known size of your texture will fit?
>
>
>
>
>
>
>___
>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 prevent OSG linking against Desktop OpenGL

[werner.modenb...@texion.eu]

Hi Daniel,
We are also using OSG together with modeen shaders like geometry shaders. We 
have to do a lot of online presentations and online support. This works perfect 
with TeamViewer. May this be an option for you?

On 9. September 2016 18:04:13 MESZ, Daniel Neos  wrote:
>Hi,
>
>my Applcation mainly uses Qt(with QOpenGlWidget) and OpensceneGraph,
>thus it relies heavily on OpenGL.
>
>Since the Remote Desktop Protocol(RDP) poorly supports OpenGL, there is
>no trivial way to run
>my application over Windows Remote Desktop. Hence, I choose to use
>Softwarerendering as a fallback.
>
>I can tell Qt which opengl version to use programmatically with
>QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL, true);
>or QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL, true);
>
>But osg seems to strictly link against opengl.dll from the desktop
>version, no matter if i am delay loading the osg*.dll i am using or
>not.
>
>When delay loading the osg*.dll , the desktop version will be loaded
>when the application makes it first contact with osg-related stuff, 
>in my case it is an objects which inherits from QOpenGLWidget
>integrating the openscenegraph view
>
>
>Code:
>
>OSGWidget::OSGWidget(QWidget* parent, Qt::WindowFlags f)
>: QOpenGLWidget(parent, f)
>, m_graphicsWindow(new osgViewer::GraphicsWindowEmbedded(x(),
>y(),
>width(),
>height()))
>, m_geometry(new osg::Geometry())
>, m_isInitialized(false)
>, m_compositeViewer(new osgViewer::CompositeViewer)
>, m_camera(new osg::Camera)
>, m_view(new OsgView)
>, m_geometryNode(new osg::Geode)
>, m_pickEventHandler(new
>PickEventHandler(static_cast(*this)))
>, m_camManipulator(new OsgCameraManipulator)
>, m_depthData(nullptr)
>, m_markedPoint(QPoint(DepthDataSet::InvalidPixelCoordinateValue,
>DepthDataSet::InvalidPixelCoordinateValue))
>, m_isMarkedPointVisible(false)
>, m_isRendering(false)
>{
>}
>
>
>
>
>
>Everything works fine using the desktop version of openg. But If I am
>trying to link against the opengl32sw.dll(from Qt), 
>osg seems to ignore it and links the desktopOpenGL.
>
>The leads to the problem that the application crashes in the deep of
>osg.
>To be more specific, here is an excerpt of the callstack from top to
>bottom.
>
>->OSGWidget::paintGL()
> ->m_compositeViewer->renderingTraversals()
>  -> ViewerBase::makeCurrent()
>   -> osg::GraphicsContext::makeCurrent() 
>-> osg::State::initializeExtensionProcs()
>
>
>Here I need to say that my first step is trying to run the application
>with
>software rendering only, before switching to Remote Desktop.
>
>
>I suspect that the mixture of the opengl32.dll versions leads to crash
>the application or maybe
>even somethings is wrong with the opengl32sw.dll from Qt. But
>everything non-related to osg seems
>to be displayed fine. I am using osg 3.4.0 and Qt 5.7
>
>
>So how can I run osg Code based on Software rendering?
>
>
>
>
>
>Thank you!
>
>Cheers,
>Daniel[/b][/code]
>
>--
>Read this topic online here:
>http://forum.openscenegraph.org/viewtopic.php?p=68563#68563
>
>
>
>
>
>___
>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