Re: [osg-users] Calling setUseVertexAttributeAliasing(true) after a viewer is being "run" causes a crasch
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
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
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
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
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 <http://www.openscenegraph.org>, 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
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
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
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
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
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 <http://groups.google.com/group/mojolicious/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
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
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
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
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
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
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
[osg-users] Placing OSG graphics in an FLTK Fl_Gl_Window
My apologies in advance if what I am asking for is either preposterous or un-achievable. I was wanting to use the FLTK forms package as a frontend for for a visualization of a finite element (FEA) model using osg as the rendering agent. As a start, I was able to get the provided example code: osgviewerFLTK compiled, linked and running and it did well. (Did this on Windows 10 using Visual Studio 2019) But, as per design, it creates its own window. What I was hoping to do was create a simple FLTK form and place an Fl_Gl_Window on it and then have osg place the rendering in that window (or some similar FLTK widget). That way, using buttons, menus, etc. I could control the rendering to my liking. I have already done something similar using a VB.Net form with a C++ DLL backend, but was wanting to transition to an all C++ solution and how to do it with FLTK presently escapes me. I was hoping that one of the members here had already plowed that ground and could post a bare-bones example of how they did it. Your help would be most appreciated. Thanks, Bob Kiser -- 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/c6ddad69-a74a-42ab-9965-176122065195n%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/osgEarth vs VulkanSceneGraph/vsgpagedlod
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
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
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
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?
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
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?
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?
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
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
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?
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
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
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
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
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?
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
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
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
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
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
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
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
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
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.
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
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.
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/o
Re: [osg-users] camera functionality issue
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
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.
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
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
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
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
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
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
the sensible thing and call m_Root = nullptr and let the smart pointer do it's job in clean up you release the pointer and then manually delete it. It's painful to see such a combination a misuse of the OSG. I don't know where you have picked up this coding style, but it's never been part of the OSG usage, none of the OSG examples, none of books, never in it's near 20 year history has abusing ref_ptr<> in this way been advocated. I don't know the history of your application, it could be that you've inherited bad code and have been thrown in the deepened trying to learn and fix stuff at the same time. From this point, I am pretty sure that the regression you see in going from 3.6.0 to 3.6.4 is likely to mis-use of the OSG in your application code that make it's so fragile and dependent on accidental behaviors to function. Fixing bugs on the OSG then can easily break your application as it was relying on buggy behavior. >From the little snippets I've picked up a number of problems, fixing these might work around the problems, but my guess is that there are major problem throughout the code. The good news is that if you learn to use the OSG a bit more appropriately your codebase will become smaller, cleaner, easier to maintain, more robust, more fun to work with. Spending a bit of time learning about how smart pointers work and how to use them will really help you. You have accesses to the full OSG source code so if you aren't sure about something just have a look at the code, put break points into the code, see what happens when smart pointers do there thing. Have a look through the examples, discussions online, have a look at the OSG books. This investment in learning more about the how thing work will make you much more productive. Best of luck, 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/56cb1ab8-754c-40a4-a9f4-dc47654e11f1%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQtWidget in dynamic library
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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_po
Re: [osg-users] Notification
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
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