Re: [osg-users] Calling setUseVertexAttributeAliasing(true) after a viewer is being "run" causes a crasch

[Robert Osfield]

Hi Andres,

You've posted to the mailman list, which I'm about to close, could you
subscribe/post to the osg-users googlegroup.  I'll answer the question
there.

Cheers,
Robert.

On Wed, 7 Apr 2021 at 13:33, Anders Backman  wrote:

> Hi all.
> Just noticed that it is not possible to toggle the
> setUseVertexAttributeAliasing after a viewer has been realized and
> frame/run has been called and any text is involved in the scene. The
> attached code is a modified osgViewer. If 's' (statistics) is shown after
> the call to  setUseVertexAttributeAliasing, I get a callstack, meaning it
> is not possible to toggle this feature while an application is being run.
> Is that intentional?
>
> I am running OSG 3.6.4 on Windows 10
>
> >
> osg160-osg.dll!osg::VertexArrayState::applyDisablingOfVertexAttributes(osg::State
> & state) Line 294 C++
>
> osg160-osg.dll!osg::Geometry::drawVertexArraysImplementation(osg::RenderInfo
> & renderInfo) Line 989 C++
>   osg160-osg.dll!osg::Geometry::drawImplementation(osg::RenderInfo &
> renderInfo) Line 899 C++
>   osg160-osg.dll!osg::Drawable::drawInner(osg::RenderInfo & renderInfo)
> Line 277 C++
>   osg160-osg.dll!osg::Drawable::draw(osg::RenderInfo & renderInfo) Line
> 619 C++
>   osg160-osgUtil.dll!osgUtil::RenderLeaf::render(osg::RenderInfo &
> renderInfo, osgUtil::RenderLeaf * previous) Line 84 C++
>
> osg160-osgUtil.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo &
> renderInfo, osgUtil::RenderLeaf * & previous) Line 488 C++
>
> osg160-osgUtil.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
> & renderInfo, osgUtil::RenderLeaf * & previous) Line 1408 C++
>   osg160-osgUtil.dll!osgUtil::RenderBin::draw(osg::RenderInfo &
> renderInfo, osgUtil::RenderLeaf * & previous) Line 432 C++
>   osg160-osgUtil.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo &
> renderInfo, osgUtil::RenderLeaf * & previous, bool & doCopyTexture) Line
> 934 C++
>
>
>
> --
> __
> Anders Backman, HPC2N
> 90187 Umeå University, Sweden
> and...@cs.umu.se http://www.hpc2n.umu.se
> Cell: +46-70-392 64 67
> ___
> 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] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

On Tue, 6 Apr 2021 at 15:16, Robert Osfield 
wrote:

> Unfortunately all it's not yet perfect, a few subscriptions are failing
> when I attempt to confirm the pending request with the googlegroup server
> reporting that it can't confirm the address.  This seems to be happening
> for a range of addresses, initially it looked random but now I've had two
> separate subscription attempts from the same domain fail right after each
> other with the same error so it's starting to look like some domains aren't
> playing nice with the googlegroup server for some reason.
>

I just followed up directly with one of the subscription requests and they
did reply to the confirmation email, and checking the same address - it's
in the membership list.  This suggests the googlegroup error that I got on
clicking to agree to subscription may not be a sign of complete failure.

I don't know what this means, hopefully it'll become clearer.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

Hi All,

It looks like the subscribe by email approach is working well for
non-Google users which is great news.

Unfortunately all it's not yet perfect, a few subscriptions are failing
when I attempt to confirm the pending request with the googlegroup server
reporting that it can't confirm the address.  This seems to be happening
for a range of addresses, initially it looked random but now I've had two
separate subscription attempts from the same domain fail right after each
other with the same error so it's starting to look like some domains aren't
playing nice with the googlegroup server for some reason.

Three of the addresses were US gov domains - could that be a connection?

If your subscription has failed then please email me directly on
robert.osfield at gmail.com.  I am hoping that I'll be able to just
subscribe to you directly.  Knowing a pattern of which types of domain fail
could also help with figuring out a solution.

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

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

On Tue, 6 Apr 2021 at 13:39, Rizzen  wrote:

> The message is correct in how I joined this email subscription group
> without using a Gmail address.
>

Thanks for the confirmation.


> Is there an email subscription group for VSG?
>

There's been a vsg-users google group for a couple of years, but no
instructions for how to subscribe without a google account.  Now I've got
the confirmation that it works I've added the same instructions to
vsg-users:

https://groups.google.com/g/vsg-users

Seems like a perfect opportunity for folks to test that I updated the links
correctly :-)

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BUb40DmjOda8F7DUOGAL0fsFG7-UYSD_k2t3fe8E%3D5Wcw%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

Hi All,

I have feedback that the email subscription route is working for non google
account users, so I have updated the introduction message for the osg-users
googlegroup.  Could folks review what I've written and let me know if it's
clear, links look correct etc.

Thanks,
Robert

-- New welcome message:

Welcome to the OpenSceneGraph user/developer group, a place for discussion
about use of and development of the OpenSceneGraph
, the open source, C++, OpenGL cross
platform scene graph.

To  join the list with a non google account send an empty email to:
osg-users+subscr...@googlegroups.com,. When you receive a confirmation
email reply to it with another empty email rather than clicking confirm -
this avoid any google account you have being used.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

Hi All,

I've approved a number of new subscription to the osg-users google group
today, most went through OK, but two requests failed when I clicked to
approach, groups.google reported the error message:

"1 request couldn't be approved
We're unable to send a notification to this person about the action you've
performed"

I don't know what the actual cause was - could be something as simple as an
invalid address being used. Unfortunately the entries disappeared with no
record for me to follow up on the addresses, so if your attempt has failed
let me know and provide details about what method you used for subscription.

Conversely, if you have successfully subscribed today with a non google
account let us know what method you use so that others can follow this same
approach.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWhnyizSos_EXrxU8ruTwWNEd65ZS69tubxuMcExXtivw%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWhnyizSos_EXrxU8ruTwWNEd65ZS69tubxuMcExXtivw%40mail.gmail.com.

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

This might be of use:

https://webapps.stackexchange.com/questions/13508/how-can-i-subscribe-to-a-google-mailing-list-with-a-non-google-e-mail-address/15593#15593

Looks like you may be able to send a email to
*osg-users+subscr...@googlegroups.com
* from the email account you want
to subscribe, then reply to the confirmation with a blank email, but don't
click on the confirmation link.

Failing that I can manually subscribe you.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWPpBkviFQPnouibCNnz9sjcKcu7WCzoJpJ2cZOeaa%2BPQ%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWPpBkviFQPnouibCNnz9sjcKcu7WCzoJpJ2cZOeaa%2BPQ%40mail.gmail.com.

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

Hi Wener,

On Mon, 5 Apr 2021 at 11:30, Werner Modenbach <
werner.modenb...@modenbach-ac.de> wrote:

> I followed your suggestion by replacing "myid" by my mail address, which
> isn't registered for a Google account.
>

The link I provided earlier wasn't consistent, I copied and modified one I
found on the web and it looks like the actual link address didn't update
correctly.  I think this should be the correct link:

   http://groups.google.com/group/osg-users/boxsubscribe?email=myid


> There was no error message and I was forwarded to the Login page.
> But logging in with the mail address failed with the message: "Your Google
> account could not be found" (translated myself)
>
> So I'll wait if just the login fails and I get messages from the list or
> if everything failed.
>

There is chance it was the wrong url.


>
> Will keep you informed.
>

I haven't seen your email address on the new subscriptions list - I just
OK'd 4 new join requests, 3 were for gmail addresses, one from a non gmail
address so it should be possible.

I am sure joining a google group without gmail used to be more straight
forward so it does look like google have been trying to hide/exclude all
the obvious ways.

I will keep hunting for a good solution.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

There appears to be a perception that you can only join the osg-users group 
using a Google account.  This isn't correct, plenty of folk have already 
joined using non google email addresses.  

I did a search online about subscribing and came across the suggestion of 
using a url in the form:

http://groups.google.com/group/osg-users/boxsubscribe?email=myid

If you still are struggling to subscribe then I can manually add your email 
address.  Just email me directly and I can add you.

The trick of banning everyone from joining the old osg-users looks to have 
stopped the flood of dubious subscription requests so for now the immediate 
issue of me being overwhelmed with support work is over, but it's just a 
short term hack as it bans everyone, including genuine requests.

On Sunday, 4 April 2021 at 19:43:28 UTC+1 Robert Osfield wrote:

>
>
> On Sun, 4 Apr 2021 at 19:38, merspieler  wrote:
>
>> I have to sign in? Then I'm out of luck..
>
>
> I asked what you could see on screen - whether you saw a join or sign in 
> button.
>
> You don't need to sign in to use the googlegroup - you can simply use it 
> as a mailing list.
>
>  Also please remember, this is free support, I'm trying to help you and 
> others, for free, in my own free time.
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/6e0617b5-e097-4a0a-86f6-ace8a071cf11n%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

There appears to be a perception that you can only join the osg-users group
using a Google account.  This isn't correct, plenty of folk have already
joined using non google email addresses.

I did a search online about subscribing and came across the suggestion of
using a url in the form:

http://groups.google.com/group/osg-users/boxsubscribe?email=myid


If you still are struggling to subscribe then I can manually add your email
address.  Just email me directly and I can add you.

The trick of banning everyone from joining the old osg-users looks to have
stopped the flood of dubious subscription requests so for now the immediate
issue of me being overwhelmed with support work is over, but it's just a
short term hack as it bans everyone, including genuine requests.

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

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

On Sun, 4 Apr 2021 at 19:38, merspieler  wrote:

> I have to sign in? Then I'm out of luck..


I asked what you could see on screen - whether you saw a join or sign in
button.

You don't need to sign in to use the googlegroup - you can simply use it as
a mailing list.

 Also please remember, this is free support, I'm trying to help you and
others, for free, in my own free time.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

I have come across a trick to ban all addresses except ones for a specified
domain, I've applied this, and will see if that fixes the deluge of
subscription requests.  This will however reject all new subscription
attempts.  At best it might provide a short term breather to give folks
more time to get subscribed to the osg-users google group.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

On Sun, 4 Apr 2021 at 15:13, merspieler  wrote:

> Following the link [1] I don't see a subscribe button.
>

Do you not see any "Join group" or "Sign in" option?

Could you check other groups to see if there is anything different.

As far as I can see all the options for new subscriptions are enabled.
Others have successfully subscribed this afternoon.

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

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

Hi Werner,

I am aware that google groups is far from ideal, falling back to at all is
really a sign of how poorly the developer world is served on the support
front.  Hopefully, one day there will be robust and easy to use/support
alternatively for forum/mailing list support so we can migrate over.

In the case of the google group, it isn't limited to gmail addresses/google
account you can subscribe with any email address you want.  Most of the
existing osg-users google group subscribed email addresses have nothing to
do with gmail.

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

Re: [osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

On Sun, 4 Apr 2021 at 13:08, merspieler  wrote:

> What about those who can't use the google mailing list?
>

I'm sorry I can't support folks for free on a platform that is requiring so
much of time to keep free of spam/misuse. I've supported this osg-users
mailing list for free for 20 years, unfortunately it's now become
impractical to continue support.  I wouldn't be taking this step if it
hasn't become a serious issue at my end.

As for can't use a google group, could you explain what issues you have
with subscribing and using the google group?  Perhaps others can help
suggest a way to use it.

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

[osg-users] Closing of osg-users@lists.openscenegraph.org, please subscribe to osg-users googlegroup

[Robert Osfield]

Hi All,

I have managed the osg-users mailing list for two decades with little
issues along the way, it mostly has just looked after itself.  Alas today
is the last day as it's become an attack vector for bots to an extent that
it's swamping my support work.  I'll be deleting the list later today, for
those that wish to continue with support please subscribe to the osg-users
google group:

https://groups.google.com/g/osg-users

This has become necessary as this year the osg-users and osg-submissions
lists have been under increasing target for nefarious bots that have been
attempting to subscribe a broad range of email addresses.   It's now become
a deluge - I'm getting notifications of new attempts as I type this
message, and unfortunately there isn't any means I can find for mailman to
thwart this type of broad attack, so it's requiring an ever increasing
amount of manual work from me to clear the backlog of requests.

There's also no way for me to know whether an address is a genuine
subscription so unfortunately there may be rejection that has happened
because the subscriptions are swamped by dozens of fake ones, many which
are plausible addresses.

I'm a C++/OpenGL/Vulkan programmer playing wack a mole with bots trying to
abuse the community just isn't a good use of my time nor helpful for the
osg-users community.  The osg-users google group doesn't look to be
affected by this attack vector so it'll be a far better place for us to
discuss OSG topics without the overhead of admin that the old mailman lists
now involve.

I have already deleted the osg-submissions list as it's no longer active -
github.com PR's have taken over for quite a while now.

I will leave the osg-uses mailing list up for the test of today.  Then
delete it later today or tomorrow morning.

Thanks for your patience,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph/osgEarth vs VulkanSceneGraph/vsgpagedlod

[Robert Osfield]

Hi Jason,

On Wed, 24 Mar 2021 at 15:22, Jason Beverage 
wrote:

> Very impressive Robert!  As you said, comparing osgEarth to your example
> isn't exactly apples to apples since the implementation under the hood is
> quite different but this is still great.
>

Thanks.  Indeed it's apples to oranges comparison so we shouldn't draw too
many conclusions.  I guess I could rewrite the vsgpagedlod example into an
OSG equivalent so all the settings are the same.  I'd actually be quite a
nice OSG examp[le.  My priority for the OSG is support so I'll have to
leave this to others.


> From what I've seen from your performance reporting, vsg is significantly
> faster than osg in most of your tests.  Do you have a feel for how much of
> that is just Vulkan being faster than OpenGL vs some of the other
> improvements you've made in design decisions of VSG vs OSG?  Are there any
> opportunities for porting some of the structures or concepts from VSG back
> to OSG to get some of the performance benefits you've seen in VSG in OSG?
>

The CPU overhead is much lower in the VSG than the OSG due to architecture
changes in the core Object/Node structure to reduce memory
footprint/bandwidth load and to avoid conditionals, These could be ported
into an OSG lite, but it'd break compatibility with a great many
applications - no BoundingSphere on all nodes, no NodeMask, no Callbacks,
no ancillary data stored in Object/Node.  It would break so many
applications and even the OSG itself it wouldn't be a small task to update
everything.

The differences are fundamental to the VSG delivering on the performance
capability that Vulkan provides, without it you'd only see a small %
improvement here or there if porting the OSG from OpenGL to Vulkan.  I've a
few applications and libraries that cite modest improvements when porting
to Vulkan, and don't recall any that claim 3 x to 10+ x faster than I'm
seeing on OSG vs VSG.  I think this either means the OSG is more of CPU hog
that we've long assumed or the VSG does a better job of not holding Vulkan
back by designing everything from the ground up to not get in the way as
much as possible.  I suspect it's a bit of both.

 Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BV7Wt%2BSD2OWQR8wHd-fWGu9F%3DEdpZjm6cE-cQ0rDQDEtg%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph/osgEarth vs VulkanSceneGraph/vsgpagedlod

[Robert Osfield]

Hi Nathan,

On Tue, 23 Mar 2021 at 18:26, Nathan Mielcarek  wrote:

> Great news! I look forward to using this in the near future either through
> OSG directly or osgEarth.
>

The VSG is intended as the successor to the OSG and would typically be used
instead of the OSG. The VSG is significantly faster than the OSG but is
still in development so isn't feature complete and is still a moving
target.  For now it's something folks who are happy to work on the bleeding
edge in order to get best performance.

One could integrate OSG/VSG into a single application using OpenGL/Vulkan
extensions to exchange data between them. Thomas Hogarth didn;'t some work
on this earlier in the VSG project, this work needs updating and porting to
work across all platforms.


> Was a bit amused by your comment about the accuracy on "finding your
> house". I think it's a great feature, especially considering how that data
> can be used by autonomous vehicles eventually.
>

It's impressive how so much verifiably accurate data is publically
available, also a bit unnerving.

Cheers,
Robert,

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BW1ELMrv540_3UE%3D1%3DpuFrO6WtCTrLH0%3DQkT2g46rznCg%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OpenSceneGraph/osgEarth vs VulkanSceneGraph/vsgpagedlod

[Robert Osfield]

Hi All,

Over the past 2 1/2 years I've been mainly focused on VulkanSceneGraph 
project, this isn't yet at 1.0 but it's come along nicely.  This week I 
wrote an example that illustrates how to use vsg::PagedLOD and 
vsg::ReaderWriter to implement paged database that streams data from online 
tile serves such a OpenStreetMap and ReadyMap.  It's like a very simple and 
crude demo of osgEarth style paging.

To look at the visual differences and performance differences I've recorded 
a camera animation path in osgviewer then run this same path with the same 
OpenStreetMap databasee in osgviewer using osgEarth, and then with the same 
path but using the new vsgpagedlod example. 


https://github.com/vsg-dev/vsgExamples/tree/PagedLOD/examples/nodes/vsgpagedlod

I've upload the a video of running the two applications, first the OSG then 
VSG, to youtube:

https://www.youtube.com/watch?v=nOQxr09ald4

The average fps for the 2 minutes camera animation path was 878fps for the 
OSG/osgEarth combo and 2698fps for VSG/vsgpagedlod, which is just under 3 
times faster for the Vulkan/VulkanSceneGraph.

As I explain in the video it's not an exact like for like comparison as 
osgEarth is doing blending between LODs, while the VSG/vsgpagedlod is 
selecting a higher level of detail for a given view.

The osgviewer was run with default DrawThreadPerContext threading, while 
vsgpagedlod viewer was running single threaded.  In both cases the 
osgDB::DatabasePager and equivalent vsg::DatabasePager are doing all the 
loading in a set of background threads.

The VSG supports running viewer multi-threaded but is unnecessary in this 
instance as the cull/draw traversal/dispatch are all happening less than 
half a millisecond :-)

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/b1adc63f-28b5-49b9-b200-1fcd5624b400n%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Question about array binding

[Robert Osfield]

On Wed, 10 Mar 2021 at 15:35, Werner Modenbach <
werner.modenb...@modenbach-ac.de> wrote:

> Hi Robert,
>
> I had a look at the code in osg::Geometry. The lines in question are:
>
> if ( handleVertexAttributes ){
>
> for(unsigned int index = 0; index < _vertexAttribList.size(); ++index)
>
> {
>
> const Array* array = _vertexAttribList[index].get();
>
> if (array && array->getBinding()==osg::Array::BIND_PER_VERTEX)
>
> {
>
> vas->setVertexAttribArray(state, index, array);
>
> }
>
> }
>
> }
>
> Do you remember, why the condition
> getBinding() == BIND_PER_VERTEX
> is there?
> *But(!) *the same condition is at _normalArray, _colorArray etc. and they
> are handled correct with BIND_OVERALL.
>
> I don't understand what is really done there. Sorry.
>

I'm pretty rusty with the code in question, but my guess is that this
constraint could be rather old, dating back to when vertex attribute
support was first added and mirrored the hardwiring of texture coordinates
to be per vertex.

I can't see any reason why this per vertex restriction would be needed
now.  Try the check against BIND_PER_VERTEX and see what happens.

Which version of the OSG are you using?

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

Re: [osg-users] how do I make the light always hit the front of the camera?

[Robert Osfield]

If you want a light positioned relative to View's Camera then this is what
the OSG provides by default.  You can probably just remove the LightSource
from the scene graph and rely upon it's settings.  In include/osg/View
you'll find:

   /** Options for controlling the global lighting used for the view.*/
enum LightingMode
{
NO_LIGHT,
HEADLIGHT,
SKY_LIGHT
};

/** Set the global lighting to use for this view.
  * Defaults to headlight. */
void setLightingMode(LightingMode lightingMode);

/** Get the global lighting used for this view.*/
LightingMode getLightingMode() const { return _lightingMode; }

/** Get the global light.*/
void setLight(osg::Light* light) { _light = light; }

/** Get the global lighting if assigned.*/
osg::Light* getLight() { return _light.get(); }

/** Get the const global lighting if assigned.*/
const osg::Light* getLight() const { return _light.get(); }

The vsgViewer::View class subclasses from osg::View, and osgViewer::Viewer
subclasses from osgViewer::View, so all the above methods are also
available via viewer.setLightingMode(..) etc.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Question about array binding

[Robert Osfield]

HI Werner,

I can't think of think of reason that would cause a problem.  It's quite a
while since I look at the associated code so it might be simply that I've
forgotten constraints.  Have a look at the
osg::Geometry::drawImplementation() to see if there is a constraint on
vertex attributes needing to be BIND_PER_VERTEX.

If you were using the VSG that I'd suggest running with Vulkan debug and
API layer as it's great for picking up errors.  Are there any OpenGL errors
being produced?

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

Re: [osg-users] how do I make the light always hit the front of the camera?

[Robert Osfield]

Hi ?

You don't say how you are rendering your present lights so providing
guidance on how to adjust it isn't possible, you'll need to provide more
information about your render system and what it relies upon for
controlling the position and direction of the light.

Also it's hard to understand what you mean.  Rotating something by 360
degrees takes it full circle and back to where it was originally - so this
bit makes no sense whatsoever.

The light in the scene looks to be a spot light pointing downwards,
pointing that back towards the camera would be a 90 degree rotation, but
pointing a spotlight at the camera would be pretty odd.  Could you mean
something completely different from what you are saying?

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

Re: [osg-users] Why does osg::AutoTransform node disappear when the scene is first created?

[Robert Osfield]

Hi ?

There isn't any way to know what settings are provoking these errors, the
best thing you can do is compile a debug version of the OSG and then setup
into the AutoTransform traverse method to figure out what maths is being
invoked and when the errors are occurring.

The only thing I can add is that osgText::Text has support for rotating to
screen and automatically scaling that for most purposes will make
osg::AutoTransform rendundent.  I would try to just use osgText::Text's
support for scaling and rotating and ditch the osg::AutoTransform. You'll
get better performance too.

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

Re: [osg-users] setMaxAnisotropy() Causes Segfault

[Robert Osfield]

The texture->setMaxAnisotropy() is a straight forward C++ method, the only
reason for it to crash would be for the method to be called on a nullptr or
invalid texture pointer.

Most likely the bug stems from simgear so I would suggest contacting the
FlightGear team to see if they can reproduce the crash and then hunt the
down the cause of the invalid pointer.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgTerrain and dynamic Heightmaps

[Robert Osfield]

Hi Anders,

On Wed, 17 Feb 2021 at 17:02, Anders Backman  wrote:

> I was wondering if there is any way of using the osgTerrain library by
> feeding it with a dynamic (changing over time) heightmap?
> I was thinking that most of the core features are there, including
> the DisplacementMappingTechnique for quick tesselation.
> But perhaps this is completely out of the scope for the Terrain library?
>

I don't recall writing any dynamic functionality into osgTerrain, but
DisplacementMappingTechnique would be the way I'd tackle it.

These days I'd just write my own osg::Geometry/shaders set up for this type
of work without dropping in osgTerrain, but then I'd also write with the
VulkanSceneGraph :-)

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

Re: [osg-users] How can I hide this white geometry without using the color transparency method and intersect?

[Robert Osfield]

On Mon, 8 Feb 2021 at 13:21, mirr...@gmail.com  wrote:

> system win10
>
> //Modifying the depth test sequence doesn't seem to work
> setRenderBinDetails(1001,"DepthSorteBin");
>

There isn't any specific advice we can provide as you've provided no
specific information about the problem bit of your scene graph, all we have
is a screen shot with a random white quad circled.

The best I can suggest is to look at your database in a modelling tool and
remove the offending bit of geometry/triangles.  That assumes the problem
is with some geometry in your scene.

However, you don't provide any information that we can use so my suggestion
is just a random guess as to what might be wrong.  You really have to try
and provide a clear explanation of what is your scene graph and where the
problem might be in this scene graph.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Several clipping planes

[Robert Osfield]

Hi Claudio,

Welcome to the OSG community. For your first post you sure are diving into
an advanced topic :-)

Conventionally one would do clipping using gl_ClipPlane, this is set by
osg::ClipPlane state attribute and osg::ClipNode to place one or more
ClipPlane in a final position in space,  I think OpenGL implementations
provide at least 6 clip planes, but It's while since I've head my head deep
in OpenGL as I'm mostly working with Vulkan these days.  There is a hard
limit though that is driver/hardware dependent.  This type of clipping gets
applied during the traseration step just prior to the fragment shader.  It
can be used with fixed function and shader pipelines.

>From your description it sounds like something custom will be best, which
in essence would be to use a fragment shader test to discard/fade out
fragments based on some combination of uniform or vertex attribute settings.

Is the clipping always going to base on a horizontal plane?  If so then you
just need to encode the height to clip at for each object via a uniform or
more efficiently with a vertex attribute bound with BIND_OVERALL.  Uniforms
have a higher overhead than vertex attributes in OSG/OpenGL so general best
used for rarely changing values, with values that change with high
frequency i.e. different for each object using vertex attributes will be
more efficient.

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

Re: [osg-users] getting userData or accumulated Uniform in nodevisitor

[Robert Osfield]

On Tue, 2 Feb 2021 at 10:38, Werner Modenbach <
werner.modenb...@modenbach-ac.de> wrote:

> Hi Robert,
>

Replying to osg-users list so that others can chip in with insights or
learn from the discussion.


> I think I'm close to getting the solution.
> Unfortunately the CullStack doesn't handle any StateSets.
> I also do not really understand what a StateGraph is.
> I just guess, calling *CullVisitor->getCurrentStateGraph()->_stateSet *gives
> me the accumulated StateSet.
> Am I right?
> Or is the accumulation of StateSets somewhere in CullVisitor->getState()?
> But there is no method for just querying a uniform in State.
> Most of the classes have only push(), pop() or apply() methods. No query
> methods.
>

I have touched this code for years so you are probably more familiar with
it now than I.

>From the top of my head the CullVisitor doesn't directly manage individual
state components like Uniform, just the high level StateSet.  The results
of the Cull traversal are passed on to the a osgUitl::StateGraph that
remains at the StateSet levels, it's only once this StateGraph is applied
during the draw traversal does the OSG's draw traversal behind to handle
the individual components of state like models, attributes and modes, and
this is done via osg::State.

What you are wanting to do is out of the ordinary, it's not something the
OSG was specifically designed to do.  Whether your approach is really
necessary or the best approach I don't know - I'm just trying to answer
questions.  When you do go beyond what the OSG was originally envisaged to
do you'll need to accept that you'll need to dig into code and figure stuff
out, I can only help you so much.

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

Re: [osg-users] getting userData or accumulated Uniform in nodevisitor

[Robert Osfield]

On Mon, 1 Feb 2021 at 10:38, 杨光  wrote:

> Hello, I’m sorry to ask you, I use shader on osgearth, the coloring effect
> is unsatisfactory, and the coloring area will change with the movement of
> the camera, can you give some hints on this question ?
>

If you have an unrelated question it's inappropriate to piggyback off
another thread as it makes it harder for everyone to follow.  It'd be rude
to interrupt someone else's conversation in real-life, online forum/mailing
list as just the same. Please start your own thread for your question.

For osgEarth related questions there is a dedicated community for it so
it's likely to be the best place to ask questions about it there.

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

Re: [osg-users] getting userData or accumulated Uniform in nodevisitor

[Robert Osfield]

Hi Werner,

You'll need to override the Cull traversal behavior and get the StateSet
stack from the CullVisitor.  I don't recall the details off the top of my
head so you'll need to look at the osgUtil::CullVisitor and it's parent
class osg::CullStack for the tracking of state.

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

Re: [osg-users] How to achieve osg::Texture2D rotation 180?

[Robert Osfield]

On Mon, 25 Jan 2021 at 07:39, mirr...@gmail.com  wrote:

> Thank you very much, but this method only works for four point texture
> coordinates
>

You provide so little information about the context about what you want to
do folks are left guessing what might be appropriate.

For instance, are you wanting to physically modify the image data so it's
rotation 180?

Or are you just wanting to modify the texture coordinates of your geometry
so the texture appears 180 different?

How to do both are completely different.  Which is appropriate for your
case we have no clue.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera render order and Threading models

[Robert Osfield]

Hi Ricard,

Both the RTT Camera and the main Camera should both be traversed in the
cull traversal within the same frame and accumulated modelview matrices
cached in the rendering backend to sent to the GPU as part of the draw
traversal together.  Ordinarily this system should prevent problems like
your describe as the rendering backend is double buffered so that the cull
writes to the currently recording frames rendering backend, while the draw
traverses the previous rendering backend structures.

The behaviour you describe makes it seem like some state is being modified
across the frames, I don't have your app or data so can't say what this
might be.  The best I can suggest is to investigate what state seems to be
changed inappropriately.  It might be that you need to double buffer the
state that is being updated whilst it's being used for rendering.

Robert

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWM4Cn4KooZoHxnv2nncmpHtrftT1aNEjGNnwows06OGA%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 回复:Re: remove updatecallback stably and reliably

[Robert Osfield]

How are the symbols represented in the scene graph and on screen?  How many
different types of symbols do you have?

What are the dynamic aspects to the simulated objects, as you mention
AnimationPathCallback I presume you are animating a transform.  Is this
just xyz translations?

I don't yet understand enough about the specific usage case but in
principle I'd suggest looking at geometry instancing as a possible
technique for leveraging the GPU more and minimizing the CPU overhead.  It
may be possible to just position your objects using an osg::UniformArray
and an appropriate shader to unpack this and create the required modelview
matrix to position/colour each instance of a symbol.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] remove updatecallback stably and reliably

[Robert Osfield]

On Sun, 27 Dec 2020 at 01:01, 蔡少波  wrote:

>I have some problems encountered in the project to ask everyone.
>

As a general tip, it's best to post a single question per post so that the
threads that follow can remain focused on one topic rather than have
several topics all interleaved together making it harder to follow and
harder for others later who are searching for answers.



> Question 1: The following function parameter t does not seem to be set to
> the specified value. It is found in the callback function of osg::Node that
> even if t is set to the specified value, the ReferenceTime in the callback
> function still starts from 0. Is there any way to make ReferenceTime from
> the specified value?
> viewer->getFrameStamp()->setReferenceTime(double t)
>

The FrameStamp has a ReferenceTime and SimulationTime, for animations it's
recommended you use the SimulationTIme.

The FrameStamp is set on each new frame in the Viewer::advance(double
simulationTime) method, so if you are writing your own frame loop you'll
call this with the parameter you want.

If you are calling the higher level Viewer::frame() method then it also
takes the optional simulationTime, or the higher still Viewer::run() that
also takes an optional double parameter for setting the simulationTime.



> Question 2: osg:Group cannot generate and add a large number of nodes at
> one time, nor can it repeatedly add and delete all child nodes, otherwise
> it will crash. Is there any way to add a large number of nodes at once?
> Can repeatedly add and delete a large number of child nodes?
>

You can add and removing large number of children but how to do it safely
will depend upon the threading model your applcation you are using and how
you got about adding/removing the nodes.

As a general note, it's likely very inefficient to create and delete
objects, especially ones that OpenGL objects associated with them.  If you
can reuse data or change how you do things to avoid creating and deleting
entirely then this will be the most efficient way to do things.  For
instance it may be possible to move work entirely to the GPU so the scene
graph itself is almost entirely static and only uniforms or small packets
of data need updating each frame.

You don't provide any information about how you are doing things or for
what reason so we can't provide any specific recommendations.  The best
thing to do would be to take a big step back and describe what you are
trying to achieve in your application from a really high level rather
diving into low level details about how you've decided to implement
something.


> Question 3: How to remove the updatecallback of a node stably and
> reliably? How to remove a node that is being updated stably and reliably?
>My rendering is done in a separate thread,
> while(!viewer->done())
> {
> osg->PreFrameUpdate();
> viewer->frame();
> osg->PostFrameUpdate();
> }
> I call node->removeUpdateCallback(callback) in the
> preFrameOpration->Operation()  function  will cause a crash.
>   I call node->setUpdateCallback(callback) again for a node that has
> already called node->setUpdateCallback(callback) will cause a crash.
> Do you have a stable and reliable way to achieve this goal?
> void PreFrameUpdate()
> {
>if (preFrameOpration != nullptr)
>{
>   preFrameOpration->Operation();
>   delete preFrameOpration;
>  preFrameOpration = nullptr;
>  }
> }
>

Again you don't really provide enough information for us to be able to
guide you in a specific direction.

Best I can say is that the osgViewer by default will run the
Viewer::frame() operations multi-threaded.  Running the frame loop itself
in it's own thread could also introduce problems if you are updating the
scene graph at the same time as another thread is reading it.

You could set the Viewer threading model to SingleThreaded via
viewer.setThreadingModel(osgViewer::Viewer::SingleThraeded) and see what
happens.  It might provide some insight.

But again best I can do is arm wave at this point as you've provided small
bits of you what you are doing. so much is left to our imaginations.  You
haven't provided any information about the nature of the crash/stack trace.

Rather than attempt to provide lots more low level chunks of information
the single best thing you can do it to describe what you are trying to
achieve with your application, then describe what approach you've decided
to implement and why, then go into the nature of the crash, information
about your OSG version, platform etc.

I say this as there could well be a very different approach you should be
taking that will avoid such much complexity and inefficiency.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] fuck off stop messaging me u dumb fucks

[Robert Osfield]

On Wed, 16 Dec 2020 at 08:31, michael kapelko  wrote:

> I guess we should really turn the driving autoreply thing off. It
> really looks like a spam. Especially when nobody's asking questions.
>

I tracked down the email and unsubscribed them.  Turns out the same email
address has harassed other open source mailing lists as well.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Insert an image before a text

[Robert Osfield]

Images won't render on their own you need to create some geometry to render
the texture on.  You don't mentioned anything about creating geometry but
it could easily by that you've just not mentioned it.

There is a convenience function for created a quad geometry appropriate for
rendering textures on, see:

   osg::createTexturedQuadGeometry()

The OSG examples that use this are:
:~/Dev/OpenSceneGraph/examples$ grep -r "osg::createTexturedQuadGeometry" .
./osgmovie/osgmovie.cpp:osg::Geometry* pictureQuad =
osg::createTexturedQuadGeometry(pos,
./osgmovie/osgmovie.cpp:osg::Geometry* pictureQuad =
osg::createTexturedQuadGeometry(pos,
./osgatomiccounter/osgatomiccounter.cpp:osg::Geometry * quad =
osg::createTexturedQuadGeometry(osg::Vec3f(-2.0f, 0.0f, -2.0f),
./osgcomputeshaders/osgcomputeshaders.cpp:osg::Geometry* geom =
osg::createTexturedQuadGeometry(
./osgtext3D/osgtext3D.cpp:geode->addDrawable(
osg::createTexturedQuadGeometry(osg::Vec3(0.0f,characterSize*thickness,0.0f),osg::Vec3(characterSize,0.0,0.0),osg::Vec3(0.0f,0.0,characterSize),
0.0, 0.0, 1.0, 1.0) );
./osgcatch/osgcatch.cpp:osg::Geometry* geometry =
osg::createTexturedQuadGeometry(pos,width,height);
./osgcatch/osgcatch.cpp:osg::Geometry* geometry =
osg::createTexturedQuadGeometry(pos,width,height);
./osgcatch/osgcatch.cpp:osg::Geometry* geometry =
osg::createTexturedQuadGeometry(pos,width,height);
./osgcatch/osgcatch.cpp:osg::Geometry* geometry =
osg::createTexturedQuadGeometry(pos,width,height);
./osgcatch/osgcatch.cpp:osg::Geometry* geometry =
osg::createTexturedQuadGeometry(_origin,_width,_height);
./osgcatch/osgcatch.cpp:osg::Geometry* geometry =
osg::createTexturedQuadGeometry(_origin,_width,_height);
./osgcatch/osgcatch.cpp:osg::Geometry* geometry =
osg::createTexturedQuadGeometry(_origin,_width,_height);
./osgcatch/osgcatch.cpp:osg::Geometry* geometry =
osg::createTexturedQuadGeometry(_origin,_width,_height);
./osgSSBO/osgSSBO.cpp:geom = osg::createTexturedQuadGeometry(placement,
osg::Vec3(1.0f*scale, 0.0f, 0.0f), osg::Vec3(0.0f, 0.0f,
ratio*1.0f*scale));
./osgSSBO/osgSSBO.cpp:geom = osg::createTexturedQuadGeometry(placement,
osg::Vec3(ratio*1.0f*scale, 0.0f, 0.0f), osg::Vec3(0.0f, 0.0f,
1.0f*scale));
./osgsampler/osgSampler.cpp:((osg::Geode*)geode.get())->addDrawable(
osg::createTexturedQuadGeometry(osg::Vec3(0,0,0),osg::Vec3(1,0,0),osg::Vec3(0,0,1)
));
./osgshadow/osgshadow.cpp:geode->addDrawable(
osg::createTexturedQuadGeometry( centerBase-widthVec*1.5f-depthVec*1.5f,
./osgimagesequence/osgimagesequence.cpp:geode->addDrawable(
osg::createTexturedQuadGeometry(osg::Vec3(0.0f,0.0f,0.0),
osg::Vec3(1.0f,0.0f,0.0), osg::Vec3(0.0f,0.0f,1.0f)));
./osgblenddrawbuffers/osgblenddrawbuffers.cpp:osg::Geometry* geom =
osg::createTexturedQuadGeometry(
./osgmultiplemovies/osgmultiplemovies.cpp:geo =
osg::createTexturedQuadGeometry(p, osg::Vec3(w, 0, 0), osg::Vec3(0, 0,
desired_height), 0, tex_t, tex_s, 0);
./osgmultiplemovies/osgmultiplemovies.cpp:geo =
osg::createTexturedQuadGeometry(p, osg::Vec3(w, 0, 0), osg::Vec3(0, 0,
desired_height), 0, 0, tex_s, tex_t);
./osgdeferred/osgdeferred.cpp:osg::Geometry* geom =
osg::createTexturedQuadGeometry(

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVjKer%2BAfKBgZeiRSOSVUOm57pGwnUVwxWbG5kWR27yxw%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] fuck off stop messaging me u dumb fucks

[Robert Osfield]

On Fri, 11 Dec 2020 at 19:39, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> fuck off stop messaging me u dumb fucks
>

There is never any excuse for such appalling language.

This list is only sent to addresses that are subscribed to it.   If you
no longer want to recieve posts then simply unsubscribe from it. The link
to do so is on all posts.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Robert Osfield]

Hi Stuart,

On Sun, 26 Jan 2020 at 13:46, Stuart Mentzer  wrote:

> OSG 3.6.5-rc2 built fine on Windows with VC2019 (so VC2017 is probably OK)
> and appears to be running properly in our application. If there are more
> RCs I can try to test those and I should be able to get 3.6.5 binaries
> posted soon after it is released.
>

Great thanks.


> Other than the usual mods I make to build with VC using GNU make the FBX
> plugin support has some issues that I worked around, wrt CMake usage and
> support for the newer VC and FBX versions. I can share my fixed versions if
> you would like and you tell me the best way to do that now.
>

It would be best to have 3.6.5 go out with support for recent VC and FBX
versions so would appreciate if you could generate a PR for them.  I can
merge them and make 3.6.5-rc3

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

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Robert Osfield]

HI All,

Still waiting on feedback on how well 3.6.5-rc2 is working OK.  I'm ready 
to tag 3.6.5 at my end as there are no Issue reported yet that I can look 
into resolving.

If there are no Issue's raised by Monday I'll go ahead and tag 3.6.5 stable 
release.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/756a9af1-c0d5-4795-83fc-773a3d99130b%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Textured ply file is black when loaded.

[Robert Osfield]

On Tuesday, 21 January 2020 15:03:12 UTC, Tom Pollok wrote:
>
> I converted it to ascii using MeshLab
>
> https://owncloud.iosb.fraunhofer.de/owncloud/s/KpZFxn5SCm0JFmN
>
> pw: osg
>

Thanks.  For future reference this might be useful. At this point in time I 
don't feel confident about inferring the data usage as it could be so open 
ended.  Have you come across any formal specification that MeshLab are 
assuming for their export?  Perhaps ask them.
 

> Yes, using another format is probably a better idea. Do you know which 
> format is typically used that supports binary encoding?
>

I can't answer this. The OSG is used in many different sectors with many 
different tools there isn't one binary file format that is used 
pervasively. Perhaps others in your sector might be able to advice.

Cheers,
Robert


 

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/482b7f89-7c53-4c2f-9553-21c45e4ee842%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] camera functionality issue

[Robert Osfield]

On Wednesday, 22 January 2020 05:12:31 UTC, Ravi wrote:
>
> We have got the camera panning by calculating the resultant of two 
> vectors(previous vector before panning and changed vector after panning) 
> and compared its magnitude with a value to restrict its position in camera 
> view. But when we zoom in and zoom out the magnitude of the vector that 
> geometry can cover side by side changes and hence the hardcoded value is of 
> no help to us anymore.
>

I'm afraid this is pretty meaningless out of context, I can't work out what 
you are doing let alone what you might be doing wrong, or what 
understanding is missing for you.

Do you have code that you can post that illustrates what you are doing?


 

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/181ec22b-b21e-4dde-b405-92d13ca5db1d%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Textured ply file is black when loaded.

[Robert Osfield]

On Tuesday, 21 January 2020 14:07:35 UTC, Tom Pollok wrote:
>
> I investigated a little.
>
> So it seems that the comment for texture files is actively used:
>
> comment TextureFile YourTexture_material_0_map_Kd.jpg
>
> So that needs to be parsed, and not ignored as just being a comment.
>
> The tools i used (MeshLAB and CloudCompare) are widely used in the 
> research community or industry. I guess there is no perfect documentation 
> that keeps track of every "hack", in case that is it is one.
>
> Regarding the header, ill add comments from what i understood 
>
> ply
> format ascii 1.0
>

Did you regenerate the scene, the .ply you shared earlier is a binary.  
ascii is easier to infer what is going on so the dev/debugging stage using 
ascii makes sense, then once it's working try the binary.

 

> comment VCGLIB generated
> comment TextureFile Wareneingang_material_0_map_Kd.jpg
> element vertex 99428 //number of vertices
> property float x  //vertex X coordinate
> property float y  //vertex Y coordinate
> property float z //vertex Z coordinate
> element face 186642 //number of faces
> property list uchar int vertex_indices//means that a face consists of 
> a number of vertices, the first uchar states that there is a n uchar at the 
> beginning that states the number of vertices that make a face. Typically 
> that is 3, but thats then in the ascii or binary dump. So assuming there 
> are 3 vertices, then 3 ints (vertex indices) have to be parsed.
> property list uchar float texcoord //after the vertex indices there is a 
> list of float texture coordiantes. The uchar states the number of values. 
> So this has to be interpreted as uv coordinates like (U0, V0, U1 V1, ..., 
> Un Vn), as there are 3 vertices, there will be three times two (u+v) == six 
> floats. The U V coordinates are typically in a rage between 0/0 to 1/1, but 
> i read somewhere that they could be larger which could mean a mirroring or 
> some sort of repetition. But lets assume they are always in the range of 
> 0/0 to 1/1. 
> property uchar red  //not sure, probably a default color if the number of 
> uv coordiantes was zero because there is no texture file?
> property uchar green //not sure, probably a default color if the number 
> of uv coordiantes was zero because there is no texture file?
> property uchar blue //not sure, probably a default color if the number of 
> uv coordiantes was zero because there is no texture file?
> property uchar alpha //not sure, probably a default color if the number 
> of uv coordiantes was zero because there is no texture file?
> end_header
>
> I converted the binary ply to ascii ply and there is one line of a vertex:
>
> -7.326906 -0.92065 -15.26979 
>
> So x y z totally makes sense.
>
> Here is the line of a face:
>
> *3* 74350 89839 97021 *6* 0.670419 0.990827 0.669870 0.993111 0.668217 
> 0.991639 255 255 255 255
>
> So the explanation in the header makes sense.
>

It's makes partial sense... each far having 6 additional floats and a red, 
green, blue, alpha colour.  How one is supposed to interpret those 6 floats 
seems to be left to the implementation to infer that it means each vertex 
has a Vec2(u,v) value for it, that's an inference based on this particular 
dataset, there doesn't look to be an formal mapping.

The design of the format looks like each face could have any number of 
floats in the list, so one face could legally have 0 additional floats, 
while the next could have 10, then the next 1 and so for.  To parse the 
texcoord as a Vec2(u,v) one would have to make sure that there are 6 
floats, and also since the OSG binds the vertex, normal and texcoords 
arrays as BIND_PER_VERTEX one would need to duplicate the vertex and 
normals to match the per corner texcoords.   

Then after generating all the geometry one would probably be best to run a 
mesh optimizer to remove all the duplicate vertices/normal/texcoord pairs 
and reset all the triangle indices.  To not due this optimization pass 
would likely lead to massively larger and inefficient geometries.

It's all possible but does all require a bit of work and inference that 
that's how the data is intended to be used.

This all tells me that PLY might be used in some sectors but it really 
isn't a good format for doing so, it likely would be far better to use a 
more standardized format that doesn't have implicit mappings that you have 
to infer based on the data that some 3rd party tools have chosen to pump 
out.

Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/f7625d4d-1caa-4513-aaf3-34c6cada1cdc%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org

Re: [osg-users] camera functionality issue

[Robert Osfield]

How far have you got?  What problems do you have?

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/fb9dad1a-856f-481d-a746-68aa16d6f6ce%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] camera functionality issue

[Robert Osfield]

Could you change you user name to a human name, it helps the community to 
converse respectively.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/701c7428-1142-4aa1-a3cc-c07838005a68%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Textured ply file is black when loaded.

[Robert Osfield]

Hi Tom,

FYI, it's was a community submission back in 2009, I don't personally know 
the ply format or have done anything more than cosmetic work on this 
plugin.  I basically in the same boat as yourself in terms of ability to 
debug the format, I just have to look at the code and see what it's doing 
with your file.  It could be a buggy file, or a buggy plugin, or perhaps a 
revision to the ply specs since the OSG plugin was written.  The 
investigation might determine which.

I have begun looking into the issue with reading your ply file, I just get 
a grey model right now.  Converting to .osgt using:

   osgconv Wareneingang2.ply test.osgt

And then looking the test.osgt in an editor reveals that the model has no 
texture coordinats.

The next step was to add some debugging to the ply plugin to see what was 
happening in texture coordinates code:

diff --git a/src/osgPlugins/ply/vertexData.cpp 
b/src/osgPlugins/ply/vertexData.cpp
index f2db29e00..58293f8dd 100644
--- a/src/osgPlugins/ply/vertexData.cpp
+++ b/src/osgPlugins/ply/vertexData.cpp
@@ -174,6 +174,9 @@ void VertexData::readVertices( PlyFile* file, const int 
nVertices,
 _texcoord = new osg::Vec2Array;
 }
 
+std::cout<<"fields = "<<(fields)name, "alpha" ) )
fields |= RGBA;
if ( equal_strings( props[j]->name, "red" ) )
fields |= RGB;
if( equal_strings( props[j]->name, "ambient" ) )
fields |= AMBIENT;
if( equal_strings( props[j]->name, "diffuse_red" ) )
fields |= DIFFUSE;
if (equal_strings(props[j]->name, "specular_red"))
fields |= SPECULAR;
if (equal_strings(props[j]->name, "texture_u"))
fields |= TEXCOORD;
if (equal_strings(props[j]->name, "texture_v"))
fields |= TEXCOORD;
}

So... the plugin is only checking for texture_u and texture_v, but if we 
look at your .ply file the header has: 

ly
format binary_little_endian 1.0
comment VCGLIB generated
comment TextureFile Wareneingang_material_0_map_Kd.jpg
element vertex 99428
property float x
property float y
property float z
element face 186642
property list uchar int vertex_indices
property list uchar float texcoord
property uchar red
property uchar green
property uchar blue
property uchar alpha
end_header

Which suggests it only has a single texcoord, no texcoord_u or texcoord_v 
field that the OSG is assuming is required for textured ply files.  For a 
2D textured file I would expect two fields, like the head explicitly has to 
the x, y, z and red, green, blue, alpha values.

Does texcoord now implictly mean a x,y value?  Is there some other encoding?

A quick search online for the spec takes me to:

   http://paulbourke.net/dataformats/ply/

Which doesn't say anything explicit about texcoords so it looks like this 
is user definable in which case how to interpret things could be really 
open ended.

I haven't yet found any explanation online about what is expected in this 
case.  I know nothing about the tools you've used to create the file.  This 
my first experience with looking into the PLY spec and the actual file 
format and haven't away knowing is there is any official guide to what 
should be doing with files which using the texcoords field.  To me it looks 
like some tools have decided on their own convention and some other tools 
honour this, but without know exactly what it is I don't have anything to 
go on to make modifications to the OSG's ply plugin.

I have to defer further work on this to members of the community that 
actually use PLY files in their applications, you will have more knowledge 
than myself and what might be meant.


-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/b1f92194-53eb-42ff-a7c8-e73cd2a65b60%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Node with different projection/view matrix fixed pipeline

[Robert Osfield]

The way I'd tackle dragging of objects in model space that are billboarded 
icons would be to project the mouse coords into clip coords then into 
object space using the matrices inverse of the (projection * view * 
model).  You'd also need to compute the depth to use, this could be 
computed by taking the original object space into clip coords, then using 
this in the mouse clip coords to object space multiplication.

Hopefully this makes sense.  It's a bit of advance topic as it requires 
understanding how matrices are used in the scenegraph/3D graphics.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/27951025-2b7f-451e-ab1f-197771929a93%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to use the osgUI

[Robert Osfield]

The osgUI NodeKit was written to be used from C++ and/or Lua script.  
During development the primary focus was on making sure it was functional 
via Lua script and as part of Present3D presentations (see 
OpenSceneGraph/applicaton/present3D).

Due to the focus on Lua script usage I didn't write any C++ examples, 
instead it was all done via Lua scripts.  There a couple of Lua scripts in 
the OpenSceneGraph-Data/ui directory that illustrate it in action.  For 
example try:

 osgviewer ~/Data/OpenSceneGraph-Data/ui/TabWidget.lua.90,0,0.rot 

Note the 90,0.0.rot uses a psuedo plugin to rotate the widget that is on 
the XY plane by default to the XZ plane to fit with the OSG default viewing 
orientation (X to the east/right, Y north/forward, Z up).

The project that funded this work, after the end of the project I haven't 
had time have time to further develop.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/aa0f73fb-fbc9-48a7-bb80-b93cac8d0da2%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Robert Osfield]

Hi All,

I have just tagged the OpenSceneGraph-3.6.5-rc2:


https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.5-rc2

Please test across as many platforms and applications as you have 
available, and report success or failures here on this thread so we can 
track convergence.  All going well we'll be able to make the 3.6.5 stable 
release this week,

Thanks in advance for your help in testing/build and bug fixes :-)

Cheers,
Robert.

-- Changes since 3.6.5-rc1

Tue, 21 Jan 2020 09:43:08 +
Author : Robert Osfield
Removed stray space

Tue, 21 Jan 2020 09:32:57 +
Author : OpenSceneGraph git repository
Merge pull request #902 from mp3butcher/oqn3.6 OQN API convergence 

Tue, 21 Jan 2020 09:16:51 +
Author : OpenSceneGraph git repository
Merge pull request #903 from dedowsdi/renderstageAdd getPreRenderList, 
getPostRenderList to RenderStage.

Fri, 17 Jan 2020 18:47:49 +0800
Author : dedowsdi
Add getPreRenderList getPostRenderList to RenderStage.

Fri, 23 Aug 2019 09:59:54 +0200
Author : Daniel Trstenjak
OcclusionQueryNode: make all usages of 'updateDefaultQueryGeometry' thread 
safe

Fri, 23 Aug 2019 09:46:02 +0200
Author : Daniel Trstenjak
OcclusionQueryNode: fix resetting to default query geometryWhen the query 
geometry gets reset to its default then its
vertices have to be updated by the bounding box dimensions of
the current children of the OcclusionQueryNode.


Wed, 14 Aug 2019 11:27:40 +0200
Author : Daniel Trstenjak
OcclusionQueryNode: fix use case of user defined query geometryThe user 
defined query geometry handling has been broken in several ways.

The previous way of defining a query geometry was using the non const
`getQueryGeometry` method and overriding its members. But then
`OcclusionQueryNode` wasn't aware of the geometry change and couldn't
internally handle it correctly.

The `computeBound` method never considered a user defined query geometry and
always just overrode the vertices of the geometry.

The member `_validQueryGeometry` wasn't correctly set.

This change should fix all this issues by introducing a small backward
compatibility break. The non const `getQueryGeometry` method is removed
forcing the user to use the `setQueryGeometry` method. But then 
`OcclusionQueryNode`
is aware of the user defined query geometry and can handle it correctly.


Tue, 29 Jan 2019 14:40:16 +0100
Author : Daniel Trstenjak
OcclusionQueryNode: reset the test result of the invalid geometryThere're 
cases that the occlusion test result has been retrieved
after the query geometry has been changed, it's the result of the
geometry before the change.


Tue, 29 Jan 2019 11:37:28 +0100
Author : Daniel Trstenjak
OcclusionQueryNode: ensure a valid query geometryIf the query geometry is 
invalid then don't do any occlusion queries and
never traverse the subgraphs.


Fri, 25 Jan 2019 15:02:45 +0100
Author : Daniel Trstenjak
OcclusionQueryNode: ensure a consistent value for '_passed'

Sat, 26 Jan 2019 16:33:23 +
Author : Robert Osfield
Introduced a QueryGeometry::getQueryResult(const osg::Camera*) method as a 
more informative replacedment for QueryGeometry::getNumPixels().

Mon, 20 Jan 2020 10:37:12 +
Author : OpenSceneGraph git repository
Merge pull request #900 from dedowsdi/fix_particle_rotationFix particle 
rotation.

Fri, 17 Jan 2020 11:18:30 +0800
Author : dedowsdi
Fix particle rotation.

Fri, 17 Jan 2020 09:28:09 +
Author : Robert Osfield
Updated ChangeLog

Fri, 17 Jan 2020 09:07:58 +
Author : Robert Osfield
Moved setting of isftream locale to Model::readOBJ(..) and 
Model::readMTL(..).

Fri, 17 Jan 2020 08:54:52 +
Author : Robert Osfield
Added explict setting of local to classic to avoid local platform settings 
affecting parsing

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/f7e6d823-4e2c-45df-be32-c147aa7a193f%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Node with different projection/view matrix fixed pipeline

[Robert Osfield]

Hi Catalin,

I'm still a bit confused from your explanation.

Is it simply that you want a 2D overlay on your scene?  Have a look at the
osghud example - this uses an osg::Camera to set a user define view and
projection matrix for it's subgraph.

If you want object to be rendered like billboards within the 3D world then
there is the osg::Billboard and osg::AutoTransform classes.

Robert.

On Thu, 16 Jan 2020 at 09:07, Catalin  wrote:

> Hi Robert,
>
> I have an old code, as you know. Some objects are rendered with OpenGL,
> but before that the ViewMatrix is set to identity, as the the objects are
> having their position computed as follow:
>
> ObjectPositionView = ViewMatrix * ObjectPosition + 2D Move Vector(x,y) in
> view space
>
> ObjectPositionView already contains the ViewMatrix, so I am feeding it
> directly to the Open GL.
>
> Those object are some billboards but with the option to be moved in the
> view space, like a 2D move.
>
> If I give directly the ObjectPosition to OSG, it works fine with
> billboards but I don't know how to incorporated the 2D Move Vector, that
> vector is in the view space.
>
> On Thu, 16 Jan 2020 at 10:18, Robert Osfield 
> wrote:
>
>> Hi Catalin,
>>
>> Could you explain what you are trying to do with the rendering of this
>> node? What you are attempting to do will guide the best way to implement
>> what you need.
>>
>> Robert.
>>
>> On Thu, 16 Jan 2020 at 07:33, Catalin  wrote:
>>
>>> Hi,
>>>
>>> Is there a way to change the view matrix or projection matrix for a just
>>> a specific node in fixed pipeline mode?
>>>
>>>
>>> ___
>>> 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
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWHVMQyX5QVbJS5NRBvvu7B3CFmu13%2BpDcGFi4TQw_jRw%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWHVMQyX5QVbJS5NRBvvu7B3CFmu13%2BpDcGFi4TQw_jRw%40mail.gmail.com.

Re: [osg-users] Node with different projection/view matrix fixed pipeline

[Robert Osfield]

Hi Catalin,

Could you explain what you are trying to do with the rendering of this
node? What you are attempting to do will guide the best way to implement
what you need.

Robert.

On Thu, 16 Jan 2020 at 07:33, Catalin  wrote:

> Hi,
>
> Is there a way to change the view matrix or projection matrix for a just a
> specific node in fixed pipeline mode?
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVWkp9CrmKovoj76JcWRd69fnpjf1GAwa%2B7y3vQZe2kOA%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVWkp9CrmKovoj76JcWRd69fnpjf1GAwa%2B7y3vQZe2kOA%40mail.gmail.com.

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 1 tagged, please test

[Robert Osfield]

On Wednesday, 15 January 2020 13:15:27 UTC, Paul Leopard wrote:
>
> My comment was made with regard to 3.6.5, I am unable to build 3.6.5.  I 
> was just describing the procedure and noting that it was the same procedure 
> I've used successfully for building 3.6.4.
>

What is generated? Are errors reports?

What version of cmake or CMakeSetup are you using?

Could other Windows using trying things our as I only have a Linux system 
to test against.
 

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/34e9c95f-5b39-4e2e-8b72-50fec80ffcee%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 1 tagged, please test

[Robert Osfield]

Hi Paul,

On Tuesday, 14 January 2020 18:45:28 UTC, Paul Leopard wrote:
>
> Using my 3.6-4 procedure, no visual studio files are generated by the 
> cmake system
>
> >mkdir release_build
> >cd release_build
> >cmake ../ -DCMAKE_INSTALL_PREFIX=../ -DCMAKE_BUILD_TYPE=Release
>
> No .sln, no .vcxproj is generated
>

This thread is for testing of the OSG-3.6.5 release candidate 1, not 3.6.4, 
lots of things have been fixed since 3.6.4, so please test the 
OpenSceneGraph-3.6 branch head or the 3.6.5-rc1. 
 

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/91056bbd-9979-47cf-89cb-2fc4fadf7aef%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OpenSceneGraph-3.6.5 release candidate 1 tagged, please test

[Robert Osfield]

Hi All,

I have checked in all fixes for the reproducible bugs/build issues that 
have been reported and tag the first release candidate in prep for the up 
coming 3.6.5 stable release:


https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.5-rc1

I have tested under Kubuntu 18.04 on a AMD/Geforce 2060 system, would 
appreciate testing across all the platforms you work under and against all 
the applications you work with.  Please report success and failures here on 
this thread so I can track how well we converging towards a release.

Thanks in advance,
Robert.

-- ChangeLog since 3.6.4

Tue, 14 Jan 2020 16:29:07 +
Author : Robert Osfield
Fixed warnings

Tue, 14 Jan 2020 14:57:15 +
Author : Robert Osfield
Fixed build warning due to auto_ptr<>

Tue, 14 Jan 2020 14:42:01 +
Author : Robert Osfield
Fixed workaround for invalid indices

Mon, 13 Jan 2020 14:14:48 +
Author : OpenSceneGraph git repository
Merge pull request #895 from openscenegraph/CurrentThreadIdAdded commment 
explaining that OpenThreads::Thread::CurrentThread() r…

Mon, 13 Jan 2020 14:12:54 +
Author : Robert Osfield
Added commment explaining that OpenThreads::Thread::CurrentThread() return 
NULL on non OpenThreads thread.

Mon, 13 Jan 2020 13:41:37 +
Author : Robert Osfield
Added support for using CurrentCodePage functionality with osgText::String 
To the DXF plugin added Option string support for using 
CurrentCodePage|WidePage, UTF8, UTF16, UTF32 and FontFile=filename

Mon, 13 Jan 2020 09:58:47 +
Author : Robert Osfield
Added encoding and font setting to dxfText as a first step towards making 
these user controllable to enble handling of non default settings

Sat, 11 Jan 2020 14:39:46 +
Author : Robert Osfield
Added creation of image directories when required

Fri, 10 Jan 2020 10:12:13 +
Author : Robert Osfield
Fixed handling of _autoScaleTransitionWidthRatio<=0.0

Tue, 7 Jan 2020 11:12:18 +
Author : Robert Osfield
Implemented TextBase::compileGLObjects() with handling of VAO/VBOs to 
address bugs associated with VAO usage of Text.

Mon, 6 Jan 2020 18:39:51 +
Author : Robert Osfield
Added Thread::CurrentThreadId() method to wrap up thread id functionality 
in a more platform appropriate way.

Mon, 6 Jan 2020 10:27:18 +
Author : OpenSceneGraph git repository
Merge pull request #887 from limbolily/patch-1Fix navagation error about 
Android GLES2 example.

Mon, 6 Jan 2020 14:48:34 +0800
Author : limbolily
Fix navagation error about Android GLES2 example.Android GLES2 example use 
event queue without initializing window rectangle with graphics 
context,that produce navigation error.

Mon, 23 Dec 2019 14:20:26 +0100
Author : Michael Danilov
Fix #877 "Shift key stuck if both shifts switch keymap"Adapted the patch 
from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687332


Mon, 23 Dec 2019 14:53:17 +0000
Author : Robert Osfield
Adopted CMake's FindDCMTK.cmake variables

Sun, 22 Dec 2019 12:29:47 +
Author : OpenSceneGraph git repository
Merge pull request #874 from blobfish/occt7.4Occt7.4

Thu, 19 Dec 2019 11:46:05 -0500
Author : blobfish
Plugins: OpenCasCade: Adding 'std' prefix where needed. See Following.Prior 
to 7.4, occt had a 'using namespace std' in a header file that
was polluting dependent projects. They have since fixed it and so these
changes are required.


Thu, 19 Dec 2019 10:16:09 -0500
Author : blobfish
Plugins: Cmake: OpenCasCade: Changing header used for include directory 
search. See Following.BRepMesh.hxx is gone in occt 7.4. Now searching for 
Standard_Version.hxx, which should be more consistent.


Wed, 18 Dec 2019 14:25:07 +0000
Author : Robert Osfield
Added classic locale setting to avoid local setting of locale affecting the 
GLSL code generated.

Mon, 16 Dec 2019 17:10:39 +0000
Author : Robert Osfield
Updated ChangeLog

Mon, 16 Dec 2019 16:51:16 +0000
Author : Robert Osfield
Added automatically removal from the OjbectCache when a object or it's 
subgraph contain Texture that no longer have an osg::Image.

Mon, 16 Dec 2019 11:54:12 +
Author : OpenSceneGraph git repository
Merge pull request #871 from LaurensVoerman/commit_tgaFixfix debug compile 
error for ReaderWriterTGA

Mon, 16 Dec 2019 11:02:41 +0100
Author : Laurens Voerman
fix debug compile error for ReaderWriterTGA

Mon, 16 Dec 2019 09:40:30 +
Author : OpenSceneGraph git repository
Merge pull request #870 from 
eligovision/OpenSceneGraph-3.6_glext_fixGLExtensions's isPBOSupported and 
isVAOSupported flags fixed

Mon, 16 Dec 2019 09:40:00 +
Author : OpenSceneGraph git repository
Merge pull request #869 from eligovision/OpenSceneGraph-3.6_glextAdded FBO 
GL extensions (useful for mobile VR etc.)

Fri, 13 Dec 2019 19:40:11 +0300
Author : konstantin.matveyev
GLExtensions's isPBOSupported and isVAOSupported flags fixed for 
GLES2+GLES3 configuration

Fri, 13 Dec 2019 19:42:30 +0300
Author : konstantin.matveyev
GLExtensions's isInvalidateFramebufferSupported fla

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

[Robert Osfield]

On Tue, 14 Jan 2020 at 15:26, 'Tom Pollok' via OpenSceneGraph Users <
osg-us...@googlegroups.com> wrote:

> Thank you for the workaround.
>
> So as far as i understand you only add the texture coordinate and normal,
> if there exists one with a index greater than 0 and less then the number of
> normals or texture coordinates.
> So that means that openscenegraph now will be able to display the textured
> mesh, even if the normals are missing, right?
>

Yes, that's correct, you'll get a textured mesh with no normals assigned.

Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BU_VueNJeHtW%3DtfpWf5i-mC8JQDyTrjf8F5VZwE06MyHw%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

[Robert Osfield]

I have checked in a workaround for the invalid indices to the 3.6 branch 
and master:


https://github.com/openscenegraph/OpenSceneGraph/commit/2b9c501e18b6eded7375c0e272aff401ad9793a2

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/6c36648e-c762-4b26-b743-3e127eb061c8%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Imported .obj file not showing textures.

[Robert Osfield]

On Tuesday, 14 January 2020 14:18:21 UTC, Voerman, L. wrote:
>
> To answer my own question, not that I've joint the google group my replies 
> by e-mail to  osg-users@lists.openscenegraph.org show up in the google 
> group as well
>

I wonder if googegroups is testing the from w.r.t accepting or rejecting 
posts and the posts from osg-users aren't signed in quite the right way to 
handle this.

Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/b00f6c52-64bd-4ba5-bf8a-fbb9f144111e%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

[Robert Osfield]

I have looked at the model with the 3.6 branch and get the crash and concur 
with Luarens - the model is broken, it has normal indices assigned to the 
faces but no normal array.  The crash occurs because the OSG's obj plugin 
is assuming that if normal indices are provided they are valid normal 
indices.

Where did this model come from?

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/3ad360a9-7e3d-462c-9e6b-b21d344ccdb7%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Imported .obj file not showing textures.

[Robert Osfield]

On Tue, 14 Jan 2020 at 13:09, L. Voerman  wrote:

> repost in google group; It seems like my reply to the mailing list does
> not show up in google groups.
>

I did think I had the two working together at the end of last year but
current mailing lists are appearing, will look into it.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DepthPartition

[Robert Osfield]

On Tuesday, 14 January 2020 04:47:32 UTC, Infinite Reality wrote:
>
> What is the principle of Depth Partition?
>

Depth buffer precision is dependent upon the near/far distance ratio, the 
lower this ratio the lower the precision and more z fighting you have - 
where pixels of polygons that are close together start to be rendered in 
the wrong order, so pixels from polygons that are further away get rendered 
instead of ones that are slightly nearer.

The depth partition technique breaks the view into distinct partitions, 
this might be just two partitions or many, usually two is enough.  The 
partitions abut so the far distance of near partition equals the near 
distances of the far partition.  The partitions are rendered before the 
nearer ones with the depth buffer being cleared before the next nearest 
partition is rendered, the colour buffer is kept for each pass.

The distance of the junction between the two partitions is not the mid 
distance between the overall near/far, but is computed to keep the near/far 
ratios and hence precision the same for each partition. The OSG's depth 
partition class computes this distance for you.

One alternate to depth partitioning is to use a non linear depth buffer as 
suggested by Maxim.  This requires custom shaders to work, but as this is 
normal for modern applications anyway this isn't much extra work.  Have a 
look online for more details on these approaches.
 

 

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/a6956422-79a1-4ed8-863c-71da3d1811d5%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Clamping models to an osgTerrain

[Robert Osfield]

Doing what you describe is possible with existing functionality, it just 
isn't implemented for you.  The complicated part in this type of work is 
the meshing of the terrain to the cultural data, if you don't need this 
level of fidelity then just putting a transform above a model and inserting 
this into tile on disk would work well.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/ffa10d02-3493-4006-80a7-44e87635a503%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

[Robert Osfield]

On Friday, 10 January 2020 18:01:57 UTC, Tom Pollok wrote:
>
> When loading a textured mesh from an obj file with mtl + texture file, 
> openscenegraph crashes.
>
> I use openscenegraph 3.4.1. Does anybody know if that issue has been fixed 
> in newer versions?
>

I don;t recall reports of crashes associated with .obj.

Could you provide a link to the model that is causing the problem?

Could you provide a stack trace?

What platform are you working on?  Did you build the OSG yourself?  

What hardware are you working on?

Cheers,
Robert,

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/3cd85069-be12-48b7-96d6-679348a35f50%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Unwanted culling in 3.6.4 vs 3.5.1

[Robert Osfield]

Thanks Anders, the description and models really helped pin point the bug
and confirm fix. I have now fixed the handling of when
_autoScaleTransitionWidthRatio<=0.0


https://github.com/openscenegraph/OpenSceneGraph/commit/61c7ee76c5c059f53366f69c27c9fdf69388eced

This is checked into master and the 3.6 branch so will be part of the up
coming 3.6.5 release.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVc0SZbBvVP7YYMM3xrOXYBXcf8EUL9uusdCwSTeC-uFA%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVc0SZbBvVP7YYMM3xrOXYBXcf8EUL9uusdCwSTeC-uFA%40mail.gmail.com.

Re: [osg-users] Unwanted culling in 3.6.4 vs 3.5.1

[Robert Osfield]

As a reminder I've added an Issue with this bug on github:

   https://github.com/openscenegraph/OpenSceneGraph/issues/892
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Unwanted culling in 3.6.4 vs 3.5.1

[Robert Osfield]

Hi Anders,

On Thu, 9 Jan 2020 at 14:07, Anders Backman  wrote:

> Problem solved:
>
> obj->setAutoScaleTransitionWidthRatio(0.001f); // Was 0 earlier.
>
> This seems to be something that changed between the two versions!
> Now it works.
>

Good to hear that you've found a workaround.

There were a number of fixes made to osg::AutoTransform so it looks like
one of the changes has created a regression for your usage case.  This is
why I make so many calls for testing before release go out so we can catch
these cases where the changes are still relatively fresh in out minds.

This commit may have made the code sensitive to a zero
setAutoScaleTransitionWidthRatio :


https://github.com/openscenegraph/OpenSceneGraph/commit/92092a56ae920b41b25b984592d69a7aaba28480#diff-02ae8731c81cbf820759403a17780405

I think this PR addresses a bug associated with using AutoTransforms in
multiple views at one time.  Looking at the code I wonder if the commented
out line (line 153 of src/osg/AutoTransform.cpp):

//if (_autoScaleTransitionWidthRatio>0.0)

Is what has introduced this sensitivity to a zero value
of_autoScaleTransitionWidthRatio.
The following code block looks like it would provoke a divide by zero with
a _autoScaleTransitionWidthRatio of zero when the i and j values ended
becoming the same value.

I will need to think about what should be happening in the code in your
usage case.  Do you know what was intended with the original settings?  I'm
a bit cold on this code as it's nearly three years since I last worked on
it.

For the upcomming 3.6.5 release I'd like to get a fix checked in to handle
this case.

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

Re: [osg-users] How to realize volume rendering for medical use

[Robert Osfield]

I don't have time to look at your application right now, so have to provide 
some high level comments.  

The osgVolume NodeKit was written for volume rendering, and the effect you 
are looking for will be achievable with the right settings.

First up the blending of the volume texels is done based on the alpha 
value, in your transfer function you have an alpha of 0.0 or 0.6, I'd 
recommend that you try a gradient to see what results you get.

The OSG's tf plugin provides a native transfer function ascii file format 
that can help you set up and experiment with different transfer functions.  
the file format is in the form:

 # comment
 intensity r g b a
 intensity r g b a
 intensity r g b a

You can pass in transfer functions to the osgvolume example via --tf 
myfile.tf



-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/89a298d1-a5d0-4fde-a031-ef991542846d%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Clamping models to an osgTerrain

[Robert Osfield]

I don't know of any off the open sourced tools that do this for you.  It 
was always something I had on my wish list for VirtualPlanetBuilder but 
never had the time/funding to tackle it.

The post processing of paged database is something that has been done over 
the years for various purposes.  

Combing the TerrainTile height fields with cultral data - trees, roads, 
houses would require one to positioning of the cultral data to the 
appropriate height, then meshing the tile's height field taking into 
account the outlines/points of the cultural data being added if you want an 
exact match.  The remeshing will be the hardest part of this work, so I'd 
suggest tackling the positioning first then add the meshing later.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/25279768-6e42-4e43-9faf-1bd73057c495%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to realize volume rendering for medical use

[Robert Osfield]

Hi Yuhui,

On Sunday, 22 December 2019 08:40:00 UTC, Yuhui Ren wrote:
>
> I have a 3D medical application developed by OSG. I want to realize volume 
> rendering of CT/MRI dataset. Refer to the figure below.  I can set 
> different effects of rendering. I have browse the osgVolume. I find that 
> the transfer functions are too few to realize the effect I want. So what 
> I’m asking really if anybody has any advice. It would be really 
> appreciated, thanks!
>

I don't know what you are looking for so can't provide any specific 
advice.  

What do you mean by "the transfer functions are too few"?  

What effect do you want?
 
Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/7862df1e-a947-421a-aac3-76ede9a7ec60%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release

[Robert Osfield]

Hi Nathan,

What platform are you building with? OS/cmake/compiler versions?

What issues do you see apart form the post fix change?

Robert.

On Wed, 18 Dec 2019 at 18:10, Nathan Mielcarek  wrote:

> Hi Robert,
>
> Looks good except for the following issue I just noticed since 3.6.3:
>
> Since the 43b274f commit (Mar 21, 2019) OSG has been installing 64-bit
> libraries in /usr/local/lib instead of /usr/local/lib64 due to the
> condition of LIB_POSTFIX not being defined when using cmake > 2.8.5.
>
> Let me know if you would like me to attempt a fix, I believe it needs
> either LIB_POSTFIX re-defined when 64-bit it detected or to change
> CMakeLists.txt to use OSG_INSTALL_LIBDIR instead.
>
> Thanks,
> Nathan
>
> On Wed, Dec 18, 2019 at 8:29 AM Ravi Mathur  wrote:
>
>> Hi Robert,
>>
>> The OpenSceneGraph-3.6 branch compiles and runs properly on my OSX Mojave
>> (10.14.6) system. I tried osgviewer, several OSG examples, and my own
>> OSG-based projects.
>>
>> Thanks,
>> Ravi
>>
>> On Mon, Dec 16, 2019 at 12:16 PM Robert Osfield 
>> wrote:
>>
>>> Hi All,
>>>
>>> I have merged the outstanding pull requests and made a couple of bug
>>> fixes that are now checked into the OpenSceneGraph-3.6 branch:
>>>
>>>
>>> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6
>>>
>>> Could everyone test out this branch to see how well it's working on your
>>> build platforms and against your hardware/OS/application combinations.  If
>>> everything looks solid I make a 3.6.5 release candidate with the aim to
>>> make a 3.6.5 in January.
>>>
>>> Thanks in advance with your help in testing.
>>> Robert.
>>>
>>> *-- ChangeLog since the 3.6.4 release on 26th of July 2019:*
>>>
>>> Mon, 16 Dec 2019 16:51:16 +
>>> Author : Robert Osfield
>>> Added automatically removal from the OjbectCache when a object or it's
>>> subgraph contain Texture that no longer have an osg::Image.
>>>
>>> Mon, 16 Dec 2019 11:54:12 +
>>> Author : OpenSceneGraph git repository
>>> Merge pull request #871 from LaurensVoerman/commit_tgaFixfix debug
>>> compile error for ReaderWriterTGA
>>>
>>> Mon, 16 Dec 2019 11:02:41 +0100
>>> Author : Laurens Voerman
>>> fix debug compile error for ReaderWriterTGA
>>>
>>> Mon, 16 Dec 2019 09:40:30 +
>>> Author : OpenSceneGraph git repository
>>> Merge pull request #870 from
>>> eligovision/OpenSceneGraph-3.6_glext_fixGLExtensions's isPBOSupported and
>>> isVAOSupported flags fixed
>>>
>>> Mon, 16 Dec 2019 09:40:00 +
>>> Author : OpenSceneGraph git repository
>>> Merge pull request #869 from eligovision/OpenSceneGraph-3.6_glextAdded
>>> FBO GL extensions (useful for mobile VR etc.)
>>>
>>> Fri, 13 Dec 2019 19:40:11 +0300
>>> Author : konstantin.matveyev
>>> GLExtensions's isPBOSupported and isVAOSupported flags fixed for
>>> GLES2+GLES3 configuration
>>>
>>> Fri, 13 Dec 2019 19:42:30 +0300
>>> Author : konstantin.matveyev
>>> GLExtensions's isInvalidateFramebufferSupported flag improved
>>>
>>> Tue, 26 Nov 2019 17:17:38 +0800
>>> Author : PntAndCnt
>>> Fontconfig should be external library.Add Fontconfig to TARGET_LIBRARIES
>>> cause osg3::osgText target looking for
>>> openscegraph-Fontconfig-import-targets.cmake, which doesn't exists.
>>>
>>>
>>> Sun, 13 Oct 2019 20:24:36 +0800
>>> Author : PntAndCnt
>>> Fix a typo and invisible 3dtext in examples/osgtext.Second text
>>> alignment is wrong when "--alignment" specified.
>>>
>>> 3D text radius is too small, only SCREEN_COORDS can be seen.
>>>
>>> Text position should multiply radius.
>>>
>>>
>>> Tue, 3 Sep 2019 16:11:14 +0800
>>> Author : Kent
>>> Mered fix for internalFormat
>>>
>>> Thu, 12 Dec 2019 18:41:23 +0300
>>> Author : valid-ptr
>>> glInvalidateFramebuffer added to GLExtensions
>>>
>>> Thu, 31 Oct 2019 18:59:04 +0300
>>> Author : konstantin.matveyev
>>> glFramebufferTexture2DMultisample added to GLExtensions
>>>
>>> Tue, 10 Dec 2019 15:08:25 +0300
>>> Author : Dmitry Marakasov
>>> Add FreeBSD-specific code bits for pthread_setaffinity_np support
>>>
>>> Thu, 12 Dec 2019 13:25:44 +
>>> Author : Robert Osfield
>>>

Re: [osg-users] incorrectly imported TEXTURE_DIMENSION macro in osgText_Text.frag

[Robert Osfield]

Hi Cory,

On Wed, 18 Dec 2019 at 14:21, Cory Riddell  wrote:

> Thank you for pointing me to exactly the right spot. I made a change at
> the top of that function rather than in the spot you indicated.
>
> I set the locale immediately after the stringstream is constructed (line
> 104):
>
> std::stringstream ss;
> ss.imbue(std::locale::classic());
> ss<


This is exactly the fix I wrote 20 minutes ago, and now checked in :-)


https://github.com/openscenegraph/OpenSceneGraph/commit/1968f3d6e14fe4cdfa98df465c1f383d2bb7d8de

This fix is checked into OSG-3.6 branch and master.


> I see that the method createStateSet() is virtual. Rather than edit the
> OSG source, would you advise creating a subclass and overriding this method?
>

This is something you could do if you had to for older versions of the
OSG.  The best solution is to have it part of the stringstream setup in
Text.cpp as I'm sure this issue will crop up for others that change don't
have standard locale.

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

Re: [osg-users] incorrectly imported TEXTURE_DIMENSION macro in osgText_Text.frag

[Robert Osfield]

Hi Cory,

Looking at osgText there following line (152,
OpenSceneGraph/src/osgText/Text.cpp sets up the TEXTURE_DIMENSION:

ss.str("");
ss << float(activeFont->getTextureWidthHint());
defineList["TEXTURE_DIMENSION"] =
osg::StateSet::DefinePair(ss.str(), osg::StateAttribute::ON);

Which makes me think that the std::stringstream ss used is defaulting to
your locale and then GLSL is using the standard locale.

If this is so then setting the locale on the stringstream would be the
appropriate thing to do.

Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BW_LqHjg7Lyhnm6xS%2BuTjAPigCHu_UKRw6M9Q50Ksp87A%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BW_LqHjg7Lyhnm6xS%2BuTjAPigCHu_UKRw6M9Q50Ksp87A%40mail.gmail.com.

Re: [osg-users] incorrectly imported TEXTURE_DIMENSION macro in osgText_Text.frag

[Robert Osfield]

Hi Cory,

What version of the OSG, OS and hardware are you using?

Do you see the issue with any of the OSG examples?

What is you OS's default locale?

Looking the #defines, is this osgText related?  Or State that your
application has set up?

Cheers,
Robert.


On Tue, 17 Dec 2019 at 16:34, Cory Riddell  wrote:

> This may be related to something having to do with my locale settings,
> but for some reason the fragment shader is failing to compile. This is
> the error from the log:
>
> FRAGMENT glCompileShader "" FAILED
> FRAGMENT Shader "" infolog:
> Fragment shader failed to compile with the following errors:
> ERROR: 1:184: error(#132) Syntax error: "024.0" parse error
> ERROR: error(#273) 1 compilation errors.  No code generated
>
> When I look for the source that is echoed to the log, the problem is the
> thousands separator on line 4:
>
> Compiling C: FRAGMENT source:
> 1: #define BACKDROP_COLOR vec4(0.300, 0.300, 0.300, 1.000)
> 2: #define GLYPH_DIMENSION 240.0
> 3: #define OUTLINE 0.070
> 4: #define TEXTURE_DIMENSION 1,024.0
>
> I believe the line is generated from this pragma:
>
> #pragma import_defines( SIGNED_DISTANCE_FIELD, TEXTURE_DIMENSION,
> GLYPH_DIMENSION)
>
> At this point I'm stuck. What controls the generation of those #define
> macros? How do I tell it to use the C locale?
>
> Thanks for any help,
> Cory Riddell
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVOhFWStNiTN54cLs1BufdhxkkERynFW1KCrx1dAHTSew%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVOhFWStNiTN54cLs1BufdhxkkERynFW1KCrx1dAHTSew%40mail.gmail.com.

Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release

[Robert Osfield]

On Tuesday, 17 December 2019 21:40:37 UTC, Chris Djali / AnyOldName3 wrote:
>
> Hi Robert,
>
> OpenMW still experiences some regressions when built with OSG 3.6.x 
> instead of 3.4.1. It's completely possible they're because we're trying to 
> coerce OSG systems to do things they weren't intended to as it's a big 
> project created without much interaction with the OSG community.
>
> The two issues we're tracking are:
>
>- https://gitlab.com/OpenMW/openmw/issues/5205 the builds provided by 
>Arch Linux crash. The Arch packagers think they're not doing anything 
>abnormally, so I don't have a clue where the issue actually lies.
>
> My best guess is there is some threading issue where a slightly different 
build resulting slightly different data alignment in a race condition 
becoming critical.  That's just a guess though, there isn't any evidence in 
the thread above that can pin point any specific problem.  

Given the fickle nature of threading problems, just because it occurs in 
3.6.x but not 3.4.x doesn't mean that there has been a bug introduced after 
3.4, it just needs some condition to slightly change that cause some of the 
data in the application to be aligned different and over the application 
goes.

The best I can recommend is to run the application with valgrind 
--tool=helgrind to see if it picks up any race conditions.

>
>- 
>- https://gitlab.com/OpenMW/openmw/issues/4773 OpenGL errors we didn't 
>use to get. This hasn't been very thoroughly investigated at all.
>
> There are potentially other issues, too. I had a collection of stack 
> traces of crashes and OpenGL errors that I was working through, and not all 
> of them ended up on our tracker. As the issues I'd already brought up on 
> the forums were taking a while to flush through due to your focus on VSG, 
> tracking down OSG regressions had been put on the back burner, and I don't 
> have a huge amount of time right now. That means the best I can do if you 
> want things narrowing down is to try and get people to replicate the issues 
> with the tip of the 3.6 branch and potentially get stack traces.
>
>
Does this happen with all hardware/OS/driver combinations or just 
particular ones?

>From the glTextStorage2D documentation at 
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexStorage2D.xhtml

Errors

GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to 
target.

GL_INVALID_OPERATION is generated by glTextureStorage2D if texture is not 
the name of an existing texture object.

GL_INVALID_ENUM is generated if internalformat is not a valid sized 
internal format.

GL_INVALID_ENUM is generated if target or the effective target of texture 
is not one of the accepted targets described above.

GL_INVALID_VALUE is generated if width, height or levels are less than 1.

GL_INVALID_OPERATION is generated if target is GL_TEXTURE_1D_ARRAY or 
GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(width)⌋+1

GL_INVALID_OPERATION is generated if target is not GL_TEXTURE_1D_ARRAY or 
GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(max(width, 
height))⌋+1

Given the glTexStorage2D(GL_TEXTURE_2D, 1, GL_RGB8, 320, 320) looks valid 
on it's own we are left with:

GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to 
target.

The next step would be to put into some test code that Texture2D.cpp to 
track what is happening right before the call.  There is a 
textureObject->bind() before each call to glTexStorage2D, but perhaps this 
is failing for some reason.

GLenum texStorageSizedInternalFormat = 
extensions->isTextureStorageEnabled && (_borderWidth==0) ? 
selectSizedInternalFormat() : 0;
 if (texStorageSizedInternalFormat!=0)
 {
 textureObject = generateAndAssignTextureObject(contextID, 
GL_TEXTURE_2D, _numMipmapLevels, texStorageSizedInternalFormat, 
_textureWidth, _textureHeight, 1, _borderWidth);
 textureObject->bind();
 applyTexParameters(GL_TEXTURE_2D, state);
 extensions->glTexStorage2D( GL_TEXTURE_2D, 
osg::maximum(_numMipmapLevels,1), texStorageSizedInternalFormat,
  _textureWidth, _textureHeight);
 }
 else
 {
 GLenum internalFormat = _sourceFormat ? _sourceFormat : 
_internalFormat;
 textureObject = generateAndAssignTextureObject(contextID, 
GL_TEXTURE_2D, _numMipmapLevels, internalFormat, _textureWidth, 
_textureHeight, 1, _borderWidth);
 textureObject->bind();
 applyTexParameters(GL_TEXTURE_2D, state);
 glTexImage2D( GL_TEXTURE_2D, 0, _internalFormat,
  _textureWidth, _textureHeight, _borderWidth,
  internalFormat,
  _sourceType ? _sourceType : GL_UNSIGNED_BYTE,
  0);
}

I can't investigate either issue without being able to recreate the 
crash/GL errors myself. If either of 

[osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release

[Robert Osfield]

Hi All,

I have merged the outstanding pull requests and made a couple of bug fixes 
that are now checked into the OpenSceneGraph-3.6 branch:

https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6

Could everyone test out this branch to see how well it's working on your 
build platforms and against your hardware/OS/application combinations.  If 
everything looks solid I make a 3.6.5 release candidate with the aim to 
make a 3.6.5 in January.

Thanks in advance with your help in testing.
Robert.

*-- ChangeLog since the 3.6.4 release on 26th of July 2019:*

Mon, 16 Dec 2019 16:51:16 +
Author : Robert Osfield
Added automatically removal from the OjbectCache when a object or it's 
subgraph contain Texture that no longer have an osg::Image.

Mon, 16 Dec 2019 11:54:12 +
Author : OpenSceneGraph git repository
Merge pull request #871 from LaurensVoerman/commit_tgaFixfix debug compile 
error for ReaderWriterTGA

Mon, 16 Dec 2019 11:02:41 +0100
Author : Laurens Voerman
fix debug compile error for ReaderWriterTGA

Mon, 16 Dec 2019 09:40:30 +
Author : OpenSceneGraph git repository
Merge pull request #870 from 
eligovision/OpenSceneGraph-3.6_glext_fixGLExtensions's isPBOSupported and 
isVAOSupported flags fixed

Mon, 16 Dec 2019 09:40:00 +
Author : OpenSceneGraph git repository
Merge pull request #869 from eligovision/OpenSceneGraph-3.6_glextAdded FBO 
GL extensions (useful for mobile VR etc.)

Fri, 13 Dec 2019 19:40:11 +0300
Author : konstantin.matveyev
GLExtensions's isPBOSupported and isVAOSupported flags fixed for 
GLES2+GLES3 configuration

Fri, 13 Dec 2019 19:42:30 +0300
Author : konstantin.matveyev
GLExtensions's isInvalidateFramebufferSupported flag improved

Tue, 26 Nov 2019 17:17:38 +0800
Author : PntAndCnt
Fontconfig should be external library.Add Fontconfig to TARGET_LIBRARIES 
cause osg3::osgText target looking for
openscegraph-Fontconfig-import-targets.cmake, which doesn't exists.


Sun, 13 Oct 2019 20:24:36 +0800
Author : PntAndCnt
Fix a typo and invisible 3dtext in examples/osgtext.Second text alignment 
is wrong when "--alignment" specified.

3D text radius is too small, only SCREEN_COORDS can be seen.

Text position should multiply radius.


Tue, 3 Sep 2019 16:11:14 +0800
Author : Kent
Mered fix for internalFormat

Thu, 12 Dec 2019 18:41:23 +0300
Author : valid-ptr
glInvalidateFramebuffer added to GLExtensions

Thu, 31 Oct 2019 18:59:04 +0300
Author : konstantin.matveyev
glFramebufferTexture2DMultisample added to GLExtensions

Tue, 10 Dec 2019 15:08:25 +0300
Author : Dmitry Marakasov
Add FreeBSD-specific code bits for pthread_setaffinity_np support

Thu, 12 Dec 2019 13:25:44 +
Author : Robert Osfield
Fix linking with Xinerama

Thu, 12 Dec 2019 13:09:33 +
Author : OpenSceneGraph git repository
Merge pull request #861 from aluaces/default-ffmpegSet ffmpeg as the 
default plugin for video files.

Fri, 22 Nov 2019 21:07:36 +0100
Author : elsid
Fix clang 8 & libc++ build errorsReplace operators for implicit type 
conversion by explicit data() method to
access implementation pointer and subscript operator to access element by
index just like in std::vector.

src/osgPlugins/tga/ReaderWriterTGA.cpp:455:22: error: use of overloaded 
operator '==' is ambiguous (with operand types 'SafeArray' 
and 'long')
if (colormap == NULL)
 ^  
src/osgPlugins/tga/ReaderWriterTGA.cpp:525:16: error: use of overloaded 
operator '==' is ambiguous (with operand types 'SafeArray' 
and 'long')
if (buffer == NULL || linebuf == NULL)
~~ ^  
src/osgPlugins/tga/ReaderWriterTGA.cpp:525:35: error: use of overloaded 
operator '==' is ambiguous (with operand types 'SafeArray' 
and 'long')
if (buffer == NULL || linebuf == NULL)
  ~~~ ^  
src/osgPlugins/tga/ReaderWriterTGA.cpp:548:30: error: use of overloaded 
operator '==' is ambiguous (with operand types 'SafeArray' 
and 'long')
if (formattedMap == NULL)
 ^  
src/osgPlugins/tga/ReaderWriterTGA.cpp:574:40: error: use of overloaded 
operator '[]' is ambiguous (with operand types 'SafeArray' 
and 'int')
index = linebuf[x];
~~~^~
src/osgPlugins/tga/ReaderWriterTGA.cpp:577:50: error: use of overloaded 
operator '+' is ambiguous (with operand types 'SafeArray' 
and 'int')
index = getInt16(linebuf + x * 2);
 ~~~ ^ ~
src/osgPlugins/tga/ReaderWriterTGA.cpp:580:50: error: use of overloaded 
operator '+' is ambiguous (with operand types 'SafeArray' 
and 'int')
index = getInt24(linebuf + x * 3);
 ~~~ ^ ~
src/osgPlugins/tga/ReaderWriterTGA.cpp:583:50: error: use of overloaded 
operator '+' is ambiguous (with operand types 'SafeArray' 
and 'int')
index = getInt32(l

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Robert Osfield]

Hi Greg,

Today I worked on improving the ObectCache::releaseGLObjects() 
implementation so that it removes objects in the scene that are Texture or 
contain Textures in their subgraph, where the Texture no longer have any 
associated osg::Image. I believe this resolves the usage case :

  1.  Load the scene graph, with the Texture UnRefImageAfterApply setiings 
are set to UnrefImageAfterApply, with the loaded textures/scene graphs 
being cached in the osgDB::ObjectCache.
  2. Render the scene graph, resulting the in the scene graph images being 
unref'd from their Textures.
  3. Close the Window, which cleans up the scene graph GL obects by calling 
releaseGLObjects()
  4. Load a new scene graph with textures/objects loaded from disk and 
where possible from the ObjectCache if previously loaded and cache,  Got 
back to 2. (Rendering etc.)

I created an example that follows all these steps and it reproduced the 
problem with the textures appearing black on the second time around when 
loading an OpenFlight database.  With the fixes to 
ObjectCache::releaseGLObjects() the unref'd images are automatically 
removed from the cache as part of step 3. above, so that they aren't shared 
any more, instead new copies are loaded from disk with their image in place.

This fix is checked into the OpenSceneGraph-3.6 branch.  The commit is:


https://github.com/openscenegraph/OpenSceneGraph/commit/9ae47b921b2184788e6efe85692908bd0ba900a2

Could you please test this out.  You should be able to remove your own 
manually clearing of the ObjectCache now, as it will be done automatically 
when required.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/f779a1bf-e231-4317-8600-565dca7f4670%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

[Robert Osfield]

Hi Chris,


I'm not seeing a particularly easy way to deep-copy the rest of the stuff 
> in osg::DefaultUserDataContainer, either. The description list is a vector 
> of strings, which are deep-copied, so that's fine, but the object list is 
> harder as I'd need to cast the const off the CopyOp if I were to deep-copy 
> those objects (which is undesirable) or copy the CopyOp to get a non-const 
> version, which I can't do, as there's no way to determine if it's actually 
> a user-provided derived class. 
>


I have had a chance to look at the 
DefaultUserDataContainer::DefaultUserDataContainer(const 
DefaultUserDataContainer& udc, const osg::CopyOp& copyop) implementation 
and it looks fine for me.  Could it be that you are just interepreting 
things a bit different than the implementation provides.  

The CopyOp::Options::DEEP_COPY_ALL is what you should use if you want to 
copy all the contents of a subgraph, including a UserDataContainer.  
DEEP_COPY_ALL enables deep copy of all options.

At this point I think the implementation is correct and there is nothing to 
fix.

Robert.
 
 

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/510d2ba3-e4b2-4251-942b-7bd59443f5d4%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Robert Osfield]

On Wed, 11 Dec 2019 at 13:04, Greg D  wrote:

> I don't understand exactly what the cache does.
>

The clue is in the name, ObjectCache is cache of Objects so they can be
reused.

The cache is useful for avoid objects being loaded multiple ties,
especially important for textures as they consume a large amount of GPU
memory so maintaining duplicates can cripple performance.


>   If it has an expiration time and objects are removed after a minute or
> so (which seems to happen) it would appear it is a short-term cache,
> perhaps to increase efficiency when the model is loading,
>

The amount of time objects in cache are retained for is controlled by the
osgDB::Registry::setExpiryDelay(double), it defaults to 10 seconds, you can
set it programmatically or set the default via OSG_EXPIRY_DELAY env var.



> before it is rendered, such as re-using already loaded texture images and
> so forth.  If it is for long-term caching (keeping models in memory even
> after another model is loaded) that would be counter productive in our
> application, since the user might load several different large model files
> in a minute in some situations, and keeping all those models in memory
> would be problematic.  My preference would be to disable caching
> altogether, unless it is a short-term cache to make loading more efficient,
> in which case clearing the cache after the first render solves my problem.
>
> I have set the osgDB::Options to CACHE_NONE but it does not appear to have
> any effect on caching.  The OpenFlight model and its textures are always
> loaded from the cache if the cache contains objects.
>
> osg::ref_ptr dbOptions = new osgDB::Options();
> dbOptions->setObjectCacheHint(osgDB::Options::CACHE_NONE);
>
> osgDB::readNodeFile(fileName, dbOptions);
>
> Is this not the correct way to disable caching?
>

It's a ObjectCacheHint so plugns can be free to ignore the hint if they
want to use the cache for their own requirements.

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

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Robert Osfield]

On Monday, 9 December 2019 19:57:27 UTC, Greg D wrote:
>
> My quick fix is to clear the cache on the first render (and call clear 
> thereafter).  OpenFlight files open and render fine now.  Is this a safe 
> fix?
>
> void ViewerBase::frame(double simulationTime)
> {
> 
> osgDB::Registry::instance()->clearObjectCache();  // ADDED TO CLEAR CACHE 
> AFTER RENDER SINCE IT BECOMES CORRUPTED
> }
>
>
Adding this line to ViewerBase is a point of information about the problem 
rather than a fix.  FYI, you can override Viewer::frame() by just 
subclassing Viewer there is no need to modify the OSG itself.  You can also 
call the clear after the frame() in your own frame loop.  However, all of 
these clearObjectCache() changes are hacks around a different problem.

>From your previous post that the change to OpenFlight's use of local cache 
vs ObjectCache indicates to me that the memory optimization of unrefering 
the osg::Image after the image data has been applied to the Textures 
texture object.  If an Texture is in the cache and could be reused *and* 
the texture object data is released between the first use but before that 
Texture is later reused.

The potential fixes are :

Nt enable Texture::UnrefImageAfterApply  - this is set to true by the 
osgUtil::Optimizer's TextureVisitor.  Is you app call the Optimizer on 
loaded databases?
Don't delete the graphics contexts, instead just close the window and 
reopen it when you need it.
Don't enable the object cache usage.

A fix at the OSG would be for the OjbectCache to automatically detect the 
usage case where a Texture is in the case, it's been compiled and the image 
unreferred, the context deleted, then the Texture requested from the 
cache.   The place to do this would probably be 
ObjectCache::releaseGLObjects(osg::State* state).  It'd need to 
dynamic_cast the Objects in the cache to find the textures then 
remove the Texture from the cache if it's got UnrefImageAfter enabled and 
no osg::Image still attached to it.

Robert.




-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/d726cd31-ce28-43ce-814c-1e293da836b8%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Robert Osfield]

The explanation and code snippet doesn't tell us enough of what is going on 
in your app to be able to guess what might be wrong.

The best thing I can do at this point is flag up a couple of issues in the 
code that could be improved, or flag up stuff that seems odd.

First up a memory leak:

  osg::Group* model = dynamic_cast(osgDB::readNodeFile(
fileName, dbOptions));

   if (model != nullptr)

   {...


This code will only assign the loaded object the m_Root if the loaded model 
root node is a Group, if isn't then it'll just be leaked, never to be 
deleted.


The best way to do a read to a particular type in robust way is to use 
ref_ptr<> and the readFile(..) method i.e.


 auto model = osgDB::readRefFile(fileName, dbOptions));  // 
return a ref_ptr that internally uses an 
dynamic_cast



The next odditiyr is that you have a CleanupModel method that removes the 
whole Viewer, but you call it a View:


void OpenSceneGraphBitmap::CleanupModel()

{

   RemoveViews();

...


}


This seems like your application is conflating various different features 
together, which is a red flag by itself and makes me wonder if you have 
mis-understood the intent of the various osgViewer class available.


The new bit of related code is another sign of misuse of the how the OSG is 
intended to be used:


void OpenSceneGraphBitmap::RemoveViews()

{

   if (m_nhiCompositeViewer != nullptr)

   {

  m_nhiCompositeViewer->setDone(true);

 

  delete m_nhiCompositeViewer;

  m_nhiCompositeViewer = nullptr;

   }


The OSG has built in robust reference counting, it is almost never 
appropriate to directly delete a object, not in the scene graph, not in the 
viewer, not a whole viewer.  I suspect your application at a higher level 
is not ideally organized so the following suggestion might just gloss over 
wider problems, any I say it here as understanding ref_ptr<> usage is 
important regardless...


So your m_nhiCompositeViewer pointer should *always* be a ref_ptr<> and 
*never* a straight C pointer.  If you want to delete a viewer you just set 
the ref_ptr<> to nullptr and it'll be automatically deleted for you if no 
other references exist t it.  The above method could safely be replaced 
with a single line : m_nhiCompositeViewer = nullptr;


However, this doesn't fix the other problems in the code, it'd just fix a 
bad practice.


Next problem will need to look at is back to the 
OpenSceneGraphBitmap::CleanupModel() 
method:



void OpenSceneGraphBitmap::CleanupModel()

{

   RemoveViews();

 

   if (m_Root != nullptr) // if root already exists (already loaded 
previous scene) remove children to clean up

   {

  m_Root->releaseGLObjects();

  m_Root->removeChildren(0, m_Root->getNumChildren());

 

  void* ptr = m_Root.release();

  delete ptr;

  m_Root = nullptr;

   }

}


Here you call RemoveViews() which will delete the Viewer and all graphics 
contexts associated with it.  The you try and do some manual clean up:


   if (m_Root != nullptr) // if root already exists (already loaded 
previous scene) remove children to clean up

   {

  m_Root->releaseGLObjects();

  m_Root->removeChildren(0, m_Root->getNumChildren());


This suggest to me that you are keeping m_Root around as some form of 
global container and then trying to manage it's contents.  The code 
snippets don't say how the node and it's children.  Deleting a Viewer will 
delete all it's GraphicsContext and clean up all the scene graphs that are 
directly attached to it, but it you have scene graph elements that are 
detached from the scene graph then it can't clean up these.  If these 
detached elements contain GL objects will have already been deleted by the 
graphics context deletion, so the handles are orphaned but the OSG itself 
doesn't know about it, and calling releaseGLObjects() will release the 
handles into containers that the OSG uses to schedule deletion or reuse of 
the GL objects.  If the graphics contexts already deleted then you have to 
discard any GL handles via calling discardGLObjects() rather than 
releaseGLObjects().


The osgViewer and scene graph are design to do all the automatic clean up 
and management of GL objects behind the scenes for you, for most 
applications there should never be a need to explicitly call 
releaseGLObjects();  The OSG can't track what you detach from viewers and 
then manipulate, in these cases you really need to think whether what you 
are doing is necessary and sensible.  My strong recommendation is that 
users avoid doing this.  


Finally we have another instance of manually an object:


  void* ptr = m_Root.release();

  delete ptr;

  m_Root = nullptr;


The code tells me that m_Root is likely a ref_ptr which rather than 
just do the sensible thing and call m_Root = nullptr and 

Re: [osg-users] osgQtWidget in dynamic library

[Robert Osfield]

The above post wasn't originally from me, but the googlegroup put this post 
from  *蔡少波* beijihuohu onto another topic due to it being posted as a reply 
to the other thread but without a changed subject  Folks please just 
post directly to the list if you have a new topic, don't reply and change 
the topic as it breaks threading...

Anyway, w.r.t osgQt, it's now a separate project not maintain by me.  I 
don't personally much Qt expertise so it was never qualified to provide any 
guidance or support on Qt issues - it's why osgQt was spun out.  I'll have 
to defer to Qt OSG users to be able to answer questions like this one.

In principle I can't see why the OSG/osgQt can't by used as a dynamic 
library, because err well the OSG has always been built as a lib/dll 
combination.  Perhaps the questions isn't actually about dll's though... 
Perhaps just a Qt specific issue?  Either way I can't provide any input on 
it as right now it doesn't look like general OSG issue that I might have 
expertise on.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/0c8a48be-ed66-48e4-a2e9-b25ec3326eaa%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgQtWidget in dynamic library

[Robert Osfield]

Hi Robert,
 I am building application with Qt 5.12.6 version and openscenegraph 
3.6.2 version,but found that  the osg widget for qt work well in stand 
alone application(exe for example) and can't be loaded in 
dynamic library, that will increase the difficulty for plugin framework.
Is there a solution for this problem?

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/a098c780-5c15-4d5d-904c-3aec142b6414%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Testing cross posting from googlegroup to osg-users mailing list

[Robert Osfield]

Replying to googlegroup post from osg-users mailing list

On Thu, 5 Dec 2019 at 17:38, Robert Osfield 
wrote:

> Another test, please ignore
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSceneGraph Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/741456ba-e9fd-4c05-a96d-02e9d37ed88a%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/741456ba-e9fd-4c05-a96d-02e9d37ed88a%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BXJsO1%2BQz89AMby-%2B93kFe2-FW_VyGbE0bewg%3DHWASk3A%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Testing cross posting from googlegroup to osg-users mailing list

[Robert Osfield]

Another test, please ignore

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/741456ba-e9fd-4c05-a96d-02e9d37ed88a%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Test post of osg-users mailing list to osg-users googlegroup

[Robert Osfield]

Testing another reply from osg-users mailing list

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BV6Lodd76E8s5HLCy%3DGkRT3u%2B4xZMRA%2BsjVpRUK5iFd%2BQ%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Test post of osg-users mailing list to osg-users googlegroup

[Robert Osfield]

Testing reply from osg-users googlegroup

On Thursday, 5 December 2019 17:31:28 UTC, Robert Osfield wrote:
>
> HI All,
>
> I am just testing the cross posting of posts to osg-users mailing list to 
> the new osg-users googlegroup.
>
> Cheers,
> Robert.
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/41b04413-c614-469e-9b8c-d60fe78a191d%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Test post of osg-users mailing list to osg-users googlegroup

[Robert Osfield]

Testing reply to osg-users mailing list.

On Thu, 5 Dec 2019 at 17:30, Robert Osfield 
wrote:

> HI All,
>
> I am just testing the cross posting of posts to osg-users mailing list to
> the new osg-users googlegroup.
>
> Cheers,
> Robert.
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Test post of osg-users mailing list to osg-users googlegroup

[Robert Osfield]

HI All,

I am just testing the cross posting of posts to osg-users mailing list to
the new osg-users googlegroup.

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

Re: [osg-users] Issue with setCompileOnNextDraw

[Robert Osfield]

Hi David,

On Wed, 4 Dec 2019 at 14:50, Heitbrink, David A 
wrote:

> I am doing a setCompileOnNextDraw on each render for each camera , (I
> typically only have 1) loading my scene.
>

CompileOnNextDraw is a feature that is meant to be used sparingly such as
on start up when you are first pre compiling all new GL objects to prevent
incremental compiles from breaking frame later in the app run.

First thing you should do is remove that call and see what happens.

Do you have an idea why this line was added?

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

[osg-users] OpenSceneGraph Forum moved to googlegroups

[Robert Osfield]

Hi All,

Our old forum was generously created by a member of our community, but a
number of years ago the creator/manager of the forum moved on work in an
area unrelated to the OpenSceneGraph so the forum no longer had a
maintainer, finally the old server that was hosting has gone too.

Previous discussions in the community didn't come up with a replacement,
and as I don't have any expertise in this direction myself I have adopted
the osg-users mailing list mirror on googlegroups as the forum, so now when
you go to forum.openscenegraph you'll be redirected to:

  https://groups.google.com/forum/#!forum/osg-users

The googlegroup doesn't have a record of the membership to the old forum,
and I don't have a record either, so to use the new googlegroup forum
you'll need to register with it.

Alternatively, you can use the original osg-users mailing list, and posts
will be crossed posted automatically.

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

Re: [osg-users] Osg Text issues

[Robert Osfield]

Hi Dan,

On Wed, 20 Nov 2019 at 14:54, Dan johansson 
wrote:

> I understand its difficult to help with such little information,
> unfortunately that is all there is so i cannot provide more code regarding
> this specific case. The osgtext example looks splendid, i copied and
> replaced my code with an example there and it now looks much cleaner. I'm
> still clueless as to what caused the issue. I can add i have built OSG with
> core profile and disabled the shader pipeline, but i am still wondering
> what actual renders the text as i haven't added a shader program to it in
> the way i would with a geode/geometry structure.
>

Are you using OSG from github master or the stable 3.6.x or other release?
If you are using master I'd recommend using the latest 3.6.4 release as it
doesn't include the experimental shader pipeline work.

>From 3.6.x onwards osgText provides it's own shaders so you don't need to
provide them yourself.  I can't provide any guesses as to what is wrong
with your original code, the best thing I can do is to recommend comparing
the example code to your own to see what differences there are.

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

Re: [osg-users] Osg Text issues

[Robert Osfield]

Hi Dan,

>From the screenshot and your tiny segment of code there is no way for us to
know what might be amiss.

What happens when you run the osgtext example?

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

Re: [osg-users] DatabasePager callbacks

[Robert Osfield]

Hi Jérôme,

You can poll whether the DatabasePager::requiresUpdateSceneGraph() but
there isn't a callback mechanism for signalling.

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

Re: [osg-users] Setting a monochrome 2d texture from byte array

[Robert Osfield]

Hi Steve,

Using a monochrome texture should be as simple as using GL_ALPHA or GL_RED
as the pixel format.  The OpenSceneGraph/src/osgText/DefaultFont.cpp
provides an example of a setting up a monochrome image.

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

Re: [osg-users] [ANN] OSG 3.6.4 Windows VC++ Binaries Posted

[Robert Osfield]

Thanks Stuart.

On Fri, 1 Nov 2019 at 08:05, Stuart Mentzer  wrote:

> Hello dear OSG-community,
>
> The OSG 3.6.4 Windows binaries at https://objexx.com/OpenSceneGraph.html
> were refreshed with the latest 3rd party packages and the just-released Qt
> 5.13.2.
>
> This refresh adds support for both the old osgQt (that is now in their Qt4
> branch) and the new osgQOpenGL approach (from the current osgQt git master
> branch). This should let projects transition to osQOpenGL when they are
> ready (and can get it to work in their applications, which we haven't
> managed yet!).
>
> Best regards,
> Stuart
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=76865#76865
>
>
>
>
>
> ___
> 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] Clip plane with osg::ClipNode

[Robert Osfield]

HI Catalin,

OpenGL clip planes are positional state which requires them to be applied
with the current modelview matrix to position them in in eye coordinates
where the clipping is done on the GPU.  This positioning means that each
individual OpenGL clip plan can only be in one place at one time, which in
turn means that when the OSG applies the clipplane only the last one
applied will be the one that is effective.

Robert.

On Wed, 23 Oct 2019 at 11:48, Catalin  wrote:

> Hi,
>
> I have an issue with clipping planes, if you set 2 different clipping
> planes to 2 different objects, only the last clipping plane is used. I was
> expecting each object to be drawn with its clipping plane.
>
> osg::ref_ptr clipNode1 = new osg::ClipNode;
> clipNode1->addClipPlane(new osg::ClipPlane(0));
> clipNode1->getClipPlane(0)->setClipPlane(1.0, 0.0, 0.0, -2000.0);
>
> osg::ref_ptr clipNode2 = new osg::ClipNode;
> clipNode2->addClipPlane(new osg::ClipPlane(0));
> clipNode2->getClipPlane(0)->setClipPlane(-1.0, 0.0, 0.0, -2000.0);
>
> osg::ShapeDrawable* s1 = new osg::ShapeDrawable(new
> osg::Box(osg::Vec3(2000, 0, 0), 500));
> clipNode1->addChild(s1);
> osg::ShapeDrawable* s2 = new osg::ShapeDrawable(new
> osg::Box(osg::Vec3(-2000, 0, 0), 500));
> clipNode2->addChild(s2);
>
> Every box is shown in half because of the clipping plane.
>
> *Case 1*
> root->addChild(clipNode1);
> //root->addChild(clipNode2);
>
> [image: image.png]
>
> *Case 2*
> //root->addChild(clipNode1);
> root->addChild(clipNode2);
>
> [image: image.png]
>
> *Case 3*
> root->addChild(clipNode1);
> root->addChild(clipNode2);
>
> [image: image.png]
>
> I was expecting both boxes, S1 and S2 to be drawn.
>
> ___
> 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] multiple matrix transfromations cause severe slowness in performance

[Robert Osfield]

Hi Gianluca,

It should be possible to have thousands of transforms in your scene graph
and still get good frame rates.  The only thing that jumps to mind right
now, is could you be doing the test with a debug build?

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

Re: [osg-users] Crash on some machines while rendering a progressive line strip

[Robert Osfield]

Hi Rakesh,

I don't think we can provide much direct insight, you have the whole
application and data to test against, while we just have a snippet without
any wider information.  The crash could be caused by anything.

The best we can do is recommend tools/strategies to reproduce the crash or
pick up on race conditions.  I only work under Linux these days and use
valgrind --tool=helgrind to pick up on threading issues, this works pretty
well for catching obscure difficult to catch in testing problems.  I'm sure
there will be similar tools under Windows, but can't provide any guidance
on this as I'm not a Windows user.

The other thing you could look at is changing the way you are implementing
things.  Personally when handling this type of user interaction ->
generation of scene graph in real-time I accumulate the user input in a
thread safe queue then read from this in the update/event traversal, this
then updates the scene graph in a synchronous way avoiding any threading
issues.

The OSG also allows you create custom events and inject them in the
viewer's EventQueue.  The osc plugin implements a custom event approach,
with it providing a custom osgGA::Device that provide interface that the
viewer can use to poll the device.  You needn't go this approach, and may
just way over complicate the task, but for certain types of apps being able
to decouple the device and events makes it easier mix and match devices and
event handling.

Robert.


On Fri, 4 Oct 2019 at 19:24, Rakesh Prasad  wrote:

> Hi,
> I have a code which renders a progressive line strip. When the line strip
> is unmasked to display it crashes on some machines. I use osg 3.6.4 with
> MFC Visual Studio 2019 with V142. The same problem was observed on osg
> 3.4.0 with MFC and Visual Studio 2013 v120. I am completely clueless as why
> it would crash since its not on my machine. I dont have the crash stack and
> other variable values. I have some observations.I will list my code and try
> to explain as best as possible.
> I migrated from osg 3.4.0 hoping 3.6.4 will resolve the issue.
>
> createHUDClubHdPts is called to create the scenegraph with the arrays.
> After which every frame AddCurPtToHandClubPath is called. This function
> updates the point in the array. As the frames are rendered a line that
> progressed based on the coordinates is displayed.  The render target is a
> MFC MDI client window. The render frames are called from a thread of class
> OpenThreads::Thread
>
> While trying to debug the issue using logs.  I found that when the
> numPtsinHandClubPath value goes to 199 it crashes. We can see that the
> array size is 2000.  Everytime it used to crash after 200 values were
> updated into the coordinate vector and color vector.
>
> It has never crashed on two of my machines so I dont have the stack and
> variable values. Few remote machines it has crashed.
> Do let me know if there is any query or clarity required.
> ...
>
> Thank you!
>
> Cheers,
> Rakesh
>
> Code:
>
> //following variables are defined in COSGViewer
> osg::MatrixTransform* mtClubHandPath;
> osg::ref_ptr osgGeodeHandClubPath;
> unsigned int MaxPtsInHandCLubPath;
> osg::ref_ptr geomHandPath;
> osg::ref_ptr geomClubPath;
> osg::ref_ptr coordsHandPath;
> osg::ref_ptr coordsClubPath;
> osg::ref_ptr coloursHandPath;
> osg::ref_ptr coloursClubPath;
> osg::ref_ptr drawArrayHandPath;
> osg::ref_ptr drawArrayClubPath;
>
>
> osg::MatrixTransform* COSGViewer::createHUDClubHdPts(int X0, int Y0, int
> X1, int Y1, int textYOffset)
> {
> mtClubHandPath = new osg::MatrixTransform();
> osg::Matrix m;
> m.makeTranslate(0, 0, 0);
> mtClubHandPath->setMatrix(m);
>
> RECT rect;
> ::GetWindowRect(m_hWnd, );
>
>
> osg::ref_ptr linesGeom = new osg::Geometry();
> osgGeodeHandClubPath = new osg::Geode();
>
> osg::ref_ptr stateset =
> osgGeodeHandClubPath->getOrCreateStateSet();
>
> stateset->setMode(GL_LIGHTING, osg::StateAttribute::OFF);
> stateset->setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF);
>
> osg::ref_ptr linewidth = new osg::LineWidth();
> linewidth->setWidth(4.0f);
> stateset->setAttributeAndModes(linewidth, osg::StateAttribute::ON);
>
> unsigned int n_points = 2000;
> MaxPtsInHandCLubPath = n_points;
> numPtsinHandClubPath = 0;
> geomHandPath = new osg::Geometry();
> geomClubPath = new osg::Geometry();
>
> coordsHandPath = new osg::Vec3Array;// (n_points);
> coordsClubPath = new osg::Vec3Array;// (n_points);
> coloursHandPath = new osg::Vec4Array;// (n_points);
> coloursClubPath = new osg::Vec4Array;// (n_points);
>
>
> for (unsigned int j = 0; j < n_points; ++j) {
>
> coordsHandPath->push_back(osg::Vec3(0, 0, 0));
> 

Re: [osg-users] Notification

[Robert Osfield]

Hi Chris,

On Tue, 1 Oct 2019 at 05:08, Chris Hanson  wrote:

> This happened to this list a few years ago and it took me like a week to
> hunt it down because it was actually subscribed through a forwarding
> address different from the one that was responding.
>

Seemed to be a bit more straight forward this time thankfully.  Still odd
though.


> Doesn't this list send a confirmation email that has to be replied to by a
> human being? Seems more than accidental...
>

I don't know if mailman, or our configuration of it, sends a confirmation
email that you have to respond to.

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

Re: [osg-users] Notification

[Robert Osfield]

On Mon, 30 Sep 2019 at 11:54, michael kapelko  wrote:

> Somebody really screwed his mailing list subscriptions.
>

I looks like someone accidentally/intentionally subscribed the wsp.com
address.

I have unsubscribed this address so we should be getting this spam anymore.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] Video Integration in OSG

[Robert Osfield]

Hi Franz-Josef,

What is the problem you are seeing?  What version of the OSG, ffmpeg, what
OS etc. are you using before and after the problems.

Being open source you should be able to mix and match bits of the OSG i.e.
use older ffmpeg if you need compatibility with an older version of ffmpeg.

Cheers,
Robert.

On Thu, 26 Sep 2019 at 17:14, Franz-Josef Schneider 
wrote:

> Hi,
> my students and I use OSG since 15 years and it works fine. We create
> plugins for Mathematics and Computer Graphic lectures. One plugin
> demonstrate videos on arbitrary surfaces. We texture surfaces with video
> frame images and syncronize sound. To do this, we use osgaudio and the
> ffmpeg package.
> The problem we had is the integration of the ffmpeg package after any
> upgrade of OSG. I know OSG isn't responsible. But I don't like to waste any
> longer time for ffmpeg integration. Are there any useability alternatives
> for video generating inside OSG, may be VLC ? I found less information in
> this forum and also at GitHub so far.
>
> Cheers
>
> Franz-Josef
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=76747#76747
>
>
>
>
>
> ___
> 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