Re: [osg-users] The naming of VulkanSceneGraph

[Robert Osfield]

On Fri, 22 Jun 2018 at 00:55, Maurizio Vitale  wrote:
> well the case of Apple (computer) vs Apple (the music company) was very 
> similar: a common word and very different industries (at the time Apple was 
> not in the music/multimedia industry).

Khronos, a standards body, and an open source project supporting a
Khronos API are very different entities to two commercial companies
trying to protect their market name.

It may be possible that some within Khronos might object, but as
VulkanSceneGraph will have clear benefit for Khronos there should be a
good case for them to support it.

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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

A short note on "The importance of working in a isolation."

This thread has been ended straying away from what I intended.  It was
announcement, and never intended to a discussion or technical issues
or wish-lists, personal preferences, from the community.  It's
devolved a bit into this as I guess I was too subtle when I wrote in
the project introduction:

"We aren't looking to involve the wider community at a day to day
level in this process, or looking to collate a wish list of features:
the plan is to keep focused on scoping out the technology and
techniques."

Why is this important?  When working on big ideas you need to take a
step back, to be creative you need to be able to dart from topic to
topic at your own pace, to look at minute detail then back up to high
level as inspiration strikes.   This creative process is greatly
hampered by getting bogged down with wading through stiff that is
irrelevant or already decided, or too soon in the cycle to be able to
discuss.

I know this is hugely important as all the biggest advances that I've
made over the years in with the OpenSceneGraph have been done working
alone, just banging my head against the wall till something compelling
pops out,The State system, multi-pass, multi-stage rendering,
database paging, osgViewer, the plugin system, #pragma(tic) shader
composition have all been instigated by myself reflection on big
issues and coming up with solutions.  Those solutions later get
refined with help from the community.

For each of these steps forward the community has a great deal of
input to helping me understand what the problems that users had and
needed to be solved, sometimes there was a specific issue or issues
realised by the community that had no good solution and I went away
and came back with a solution.  Sometimes, it was years of the
community and myself struggling with an issue with no clear resolution
that was found, then suddenly a solution came to me - #pragma(tic)
shader composition is one example of the later.

For the VulkanSceneGraph project, the input I have needed to
understand what is required has been accumulated over 20 years of
working the OpenSceneGraph.  I've been witness to all of the issues
that the user community have had trying to solve their graphics
application tasks, I've been involved in tens of thousands of support
discussion, made many thousand bug fixes, many thousand reviews of
code submissions.   I really know what it's like for the community, I
know what it's like to maintain a piece of software over many years.
I need no more input at his point, I've listed to you all for nearly
two decades, all this input data is sat inside my head and has been
gestating for years.

Right now attempts at technical discussions or putting in your ideas
is not at all helpful, in fact it's a real hindrance to creativity,
it's a distraction from necessary quiet time required to come up with
coherent designs.

So the please be patient, there will be a time for technical
discussions, testing, refining, it's just not now.

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

Re: [osg-users] The naming of VulkanSceneGraph

[Maurizio Vitale]

>
> If the branding is very distinct, and the word itself isn't something that
> can be owned as there is lots of prior art in active use
>

well the case of Apple (computer) vs Apple (the music company) was very
similar: a common word and very different industries (at the time Apple was
not in the music/multimedia industry).
And the losers even had the name before Apple Computers was a thing.
IANAL, but I would bet that using Vulkan in the name is not going to be ok.

Maurizio

On Thu, Jun 21, 2018 at 11:46 AM Robert Osfield 
wrote:

> Hi Chris,
>
>
>   I am not a lawyer, but I think this is in a muddy area and it concerns
>> me. I don't think anyone here can answer this, probably the only way to
>> know is to ask Khronos directly for their interpretation in writing. But I
>> suspect the answer will be "find a different name that doesn't embed the
>> Vulkan" word mark".
>>
>>   Just hoping to avoid future pain here. I can reach out to Khronos if
>> that is what seems best to do.
>>
>
>
> The of registered trademarks is something that I have considered, but
> haven't official request permission from Khronous.  My plan is not to use
> the Vulkan logo colour, font or style in the VulkanSceneGraph logo, not
> that I've really thought too much about that, other than don't be like
> Vulkan.  Branding similar to the OpenSceneGraph would probably make sense
> as they part of the same family.  If we have to then VulcanSceneGraph would
> a bit naff fallback.
>
> If the branding is very distinct, and the word itself isn't something that
> can be owned as there is lots of prior art in active use, then I would have
> thought while a lawyer might say ohh absolutely not, in practice I suspect
> they would be unlikely to be able to defend it court.
>
> Within Khronos I suspect there will be a range of views.  Having a
> professional grade scene graph being developed explicitly on top of Vulkan
> is an asset to Vulkan adoption and promotion.  If Kronous want Vulkan to
> break out beyond the game market early adopters then the VulkanSceneGraph
> will be a great vehicle for it.  I could see that some within Khronos might
> concerned that it might be viewed as Khronos project and would detract from
> their own mission, but I'd hope this would be in the minority - or at least
> it should be as Vulkan really needs a professional grade scene graph to
> achieve widespread adoption, and having the Vulkan name in there will a
> great advert for it.
>
> I did look at the costs of trademarking VulkanSceneGraph myself but the
> for worldwide it's several tens of thousands of $ so I decided against it.
>
> I had considered finding a friendly Khronos member to introduce the
> project to with the hope that they would advocate the project.  If I were
> attending Siggraph this is when I'd do it. I am open to others taking on
> this role if they already have a good working relationship with members of
> Khronos.
>
> Getting an official OK from Khronos would be something more challenging
> and definitely require getting involved with some kinda of committee
> discussion.  Having something tangible to discuss in terms of prototype
> code and design document could be useful in this process so they can have a
> bit of confidence that the project is an asset rather than a risk.  I am
> obviously a few months away from this.
>
> Cheers,
> Robert.
>
>
>
> ___
> 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] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On Thu, 21 Jun 2018 at 17:25, Scott Bailey  wrote:

> Regarding smart pointers, Boost Libs has a mature implementation that
> includes intrusive_ptr<>.  Adding another dependency is, of course, a mixed
> bag; however, if you go header only with boost libs it's reasonable.
>
> For my projects, I have found one advantage of Boost is how often it's
> libraries migrate themselves into the standard.  There are quite a few
> other libraries in Boost I use regularly, including threading and
> filesystem.  Just something to think about.
>

Just to be clear.  I have *no* intention of making Boost a dependency, ever.

I am perfectly fine with users adding whatever dependencies they want for
their own projects but the VulkanSceneGraph will be focused on keeping the
dependencies to a minimum, Vulkan and C++11 (possibly later) and perhaps
native windowing.

If the standard committee do decide something is worth adopting from Boost
then at that time that I'll consider using that feature, but even then it
has to justify itself.

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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Scott Bailey]

Regarding smart pointers, Boost Libs has a mature implementation that includes 
intrusive_ptr<>.  Adding another dependency is, of course, a mixed bag; 
however, if you go header only with boost libs it's reasonable.  

For my projects, I have found one advantage of Boost is how often it's 
libraries migrate themselves into the standard.  There are quite a few other 
libraries in Boost I use regularly, including threading and filesystem.  Just 
something to think about.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74109#74109





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

Re: [osg-users] The naming of VulkanSceneGraph

[Robert Osfield]

Hi Chris,


  I am not a lawyer, but I think this is in a muddy area and it concerns
> me. I don't think anyone here can answer this, probably the only way to
> know is to ask Khronos directly for their interpretation in writing. But I
> suspect the answer will be "find a different name that doesn't embed the
> Vulkan" word mark".
>
>   Just hoping to avoid future pain here. I can reach out to Khronos if
> that is what seems best to do.
>


The of registered trademarks is something that I have considered, but
haven't official request permission from Khronous.  My plan is not to use
the Vulkan logo colour, font or style in the VulkanSceneGraph logo, not
that I've really thought too much about that, other than don't be like
Vulkan.  Branding similar to the OpenSceneGraph would probably make sense
as they part of the same family.  If we have to then VulcanSceneGraph would
a bit naff fallback.

If the branding is very distinct, and the word itself isn't something that
can be owned as there is lots of prior art in active use, then I would have
thought while a lawyer might say ohh absolutely not, in practice I suspect
they would be unlikely to be able to defend it court.

Within Khronos I suspect there will be a range of views.  Having a
professional grade scene graph being developed explicitly on top of Vulkan
is an asset to Vulkan adoption and promotion.  If Kronous want Vulkan to
break out beyond the game market early adopters then the VulkanSceneGraph
will be a great vehicle for it.  I could see that some within Khronos might
concerned that it might be viewed as Khronos project and would detract from
their own mission, but I'd hope this would be in the minority - or at least
it should be as Vulkan really needs a professional grade scene graph to
achieve widespread adoption, and having the Vulkan name in there will a
great advert for it.

I did look at the costs of trademarking VulkanSceneGraph myself but the for
worldwide it's several tens of thousands of $ so I decided against it.

I had considered finding a friendly Khronos member to introduce the project
to with the hope that they would advocate the project.  If I were attending
Siggraph this is when I'd do it. I am open to others taking on this role if
they already have a good working relationship with members of Khronos.

Getting an official OK from Khronos would be something more challenging and
definitely require getting involved with some kinda of committee
discussion.  Having something tangible to discuss in terms of prototype
code and design document could be useful in this process so they can have a
bit of confidence that the project is an asset rather than a risk.  I am
obviously a few months away from this.

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

[osg-users] The naming of VulkanSceneGraph

[Chris Hanson]

  Something came up in a conversation earlier this week that I thought I
would point out.

  Is VulkanSceneGraph potentially opening itself to
trademark-related hassle by incorporating the trademark "Vulkan" name into
its own name?

  The Khronos trademark guidelines are here:
https://www.khronos.org/legal/khronos-trademark-guidelines

  They mostly center around freely using the work Vulkan descriptively and
NOT using it when referring to an actual Vulkan implementation (which is
different from VSG's situation). The incorporation of the Vulkan word-mark
into a novel software product name (even a F/OSS package) seems like it
could run afoul of Khronos' intentions and lawyers.

  The historical example is that I doubt SGI and then Khronos would have
ever been ok with a prominent software package calling itself
"OpenGLSceneGraph" because they protect the word-mark "OpenGL".

  I am not a lawyer, but I think this is in a muddy area and it concerns
me. I don't think anyone here can answer this, probably the only way to
know is to ask Khronos directly for their interpretation in writing. But I
suspect the answer will be "find a different name that doesn't embed the
Vulkan" word mark".

  Just hoping to avoid future pain here. I can reach out to Khronos if that
is what seems best to do.

-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Model flickering on osgViewer

[Eran Cohen]

That does indeed fix the flickering.
My driver is Intel(R) HD Graphic 4000  ver 10.18.10.4885.



ceranco wrote:
> Hi Laurens, thanks for answering so quickly.
> I'll try your suggestion when I get home.
> 
> 
> 
> L. Voerman wrote:
> > This looks like a driver bug, an reminds me of a problem in the nvidia 
> > driver having problems with display lists combined with depth_clamp.
> > the osgviewer doesn't do the depthclamp, but the display lists might be a 
> > problem here.
> > can you try:
> > set OSG_OPTIMIZER=INDEX_MESH
> > 
> > osgviewer cow.osg
> > 
> > 
> > Laurens.
> > 
> > 
> > On Thu, Jun 21, 2018 at 12:02 PM Eran Cohen < ()> wrote:
> > 
> > 
> > > Hi,
> > > 
> > > I compiled OpenSceneGraph 3.6.1 on a recently formatted Windows 10 laptop 
> > > with up-to-date drivers. 
> > > When I tried to run osgViewer with cow.osg, the model and screen started 
> > > to 'flicker':
> > > [Image: https://preview.ibb.co/dbVWFT/photo.jpg 
> > > (https://preview.ibb.co/dbVWFT/photo.jpg) ] (https://ibb.co/jeAnpo 
> > > (https://ibb.co/jeAnpo))
> > > 
> > > but interestingly, when I took a screenshot, everything looked alright:
> > > [Image: https://preview.ibb.co/ic4u28/screenshot.jpg 
> > > (https://preview.ibb.co/ic4u28/screenshot.jpg) ] (https://ibb.co/e9ju28 
> > > (https://ibb.co/e9ju28))
> > > 
> > > Previously, the laptop was running Linux and this problem didn't happen.
> > > Does anyone have an idea why this is happening?
> > > 
> > > Thanks,
> > > Eran
> > > 
> > > --
> > > Read this topic online here:
> > > http://forum.openscenegraph.org/viewtopic.php?p=74097#74097 
> > > (http://forum.openscenegraph.org/viewtopic.php?p=74097#74097)
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > osg-users mailing list
> > >  ()
> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > > 
> > 
> > 
> >  --
> > Post generated by Mail2Forum
> 


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74106#74106





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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On Thu, 21 Jun 2018 at 12:11, Tim Moore  wrote:

> This is not the way shared_ptr is implemented, at least in gcc. The shared
> pointer contains a pointer to the object as well as to the control block.
> You could argue that this makes a shared_ptr twice the size of an
> osg::ref_ptr, but I really can't speculate on the overall effect on memory
> usage.
>

16 bytes instead of 8 for every single pointer... plus the extra shared
pointer object... is it just a pointer + atomic?

shared_ptr<> is a "solution" to how do I share types like an int, but it's
not at a good solution for situations where intrusive reference counting is
trivial to provide as part of class design.

Intrusive reference counting is a far better solution for a scene graph,
there isn't a comparison.  Frankly I can't believe I'm even having to
explain this, shared_ptr<> is a niche solution that gets way more airtime
than is deserves.



> So... as my aim where possible is to make the VulkanSceneGraph more
>> efficient than the OpenSceneGraph I can't just put chains around my ankles
>> by adopting shared_ptr<>, instead I will acknowledge where the
>> OpenSceneGraph already does something well and following this approach,
>> albeit in a modern C++ way.
>>
>> For the thread safe observer_ptr<> you do need a separate auxiliary
>> object, just like the OSG, so in my prototyping this is already what I have
>> done.  I already have an vsg::Auxiliary object that is created when
>> required, this Auxiliary object is for more than just supporting
>> observer_ptr<> though, it also stores optional extra user data.  Doing this
>> shrinks the base vsg::Object/Node classes and improves memory utilization,
>> providing a measurable gain in construction, destruction and traversal of
>> the scene graph over what can be done with the OSG.
>>
> What's the measured gain?
>

Measurable gain as in timing stats, the approach I'm exploring for the
VulkanSceneGraph is faster for creating objects, destructing objects and
traversal.  Good for all users, especially any time we are paging data.



> Of course I trust your judgement, but I struggled mightily with weak
> pointer thread safety back in the day and am happy to be able to make it
> someone else's problem now. I am very happy that VulkanSceneGraph is coming
> on the scene!
>

I remember all the pain getting is to work robustly.  My experiments build
upon what the OSG does currently, but using std::atomic, as well as
discarding a lot of baggage that the OSG has due to it's long history, it's
far, far cleaner. Yes we'll hammering with mutti-threaded stress cases to
make sure what we end up with is solid implementation, but with the
implementation being so much cleaner I expect the process to be a lot less
painful.

Things like ref_ptr<>/observer_ptr<> are just a tiny bit of what I'm
looking at in the Exploration Phase, these are really just a footnote
compared to the wider design and implementation issues.

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

Re: [osg-users] Model flickering on osgViewer

[Eran Cohen]

Hi Laurens, thanks for answering so quickly.
I'll try your suggestion when I get home.



L. Voerman wrote:
> This looks like a driver bug, an reminds me of a problem in the nvidia driver 
> having problems with display lists combined with depth_clamp.
> the osgviewer doesn't do the depthclamp, but the display lists might be a 
> problem here.
> can you try:
> set OSG_OPTIMIZER=INDEX_MESH
> 
> osgviewer cow.osg
> 
> 
> Laurens.
> 
> 
> On Thu, Jun 21, 2018 at 12:02 PM Eran Cohen < ()> wrote:
> 
> 
> > Hi,
> > 
> > I compiled OpenSceneGraph 3.6.1 on a recently formatted Windows 10 laptop 
> > with up-to-date drivers. 
> > When I tried to run osgViewer with cow.osg, the model and screen started to 
> > 'flicker':
> > [Image: https://preview.ibb.co/dbVWFT/photo.jpg 
> > (https://preview.ibb.co/dbVWFT/photo.jpg) ] (https://ibb.co/jeAnpo 
> > (https://ibb.co/jeAnpo))
> > 
> > but interestingly, when I took a screenshot, everything looked alright:
> > [Image: https://preview.ibb.co/ic4u28/screenshot.jpg 
> > (https://preview.ibb.co/ic4u28/screenshot.jpg) ] (https://ibb.co/e9ju28 
> > (https://ibb.co/e9ju28))
> > 
> > Previously, the laptop was running Linux and this problem didn't happen.
> > Does anyone have an idea why this is happening?
> > 
> > Thanks,
> > Eran
> > 
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=74097#74097 
> > (http://forum.openscenegraph.org/viewtopic.php?p=74097#74097)
> > 
> > 
> > 
> > 
> > 
> > ___
> > osg-users mailing list
> >  ()
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > 
> 
> 
>  --
> Post generated by Mail2Forum


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74104#74104





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

Re: [osg-users] LineSegmentIntersector doesn't give accurate Coordinates

[Jochen Schwitzer]

Hi,

fixed the issue. I was using a defect Drawer. Thanks anyway

Thank you!

Cheers,
Jochen

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74103#74103





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

Re: [osg-users] LineSegmentIntersector doesn't give accurate Coordinates

[Jochen Schwitzer]

Hi Robert,

thanks for your quick response.

so here's what I'm doing:


Code:

if (viewer)
{
returnValue =
ReactOnLCSPointClick(
*viewer, i_eventAdapter.getX(), i_eventAdapter.getY());
}




I tried as well with getXnormalized() and Intersector::PROJECTION but then it 
was even more far off


Code:
osg::ref_ptr intersector = new 
osgUtil::LineSegmentIntersector(
osgUtil::Intersector::WINDOW, i_clickXCoordinate, i_clickYCoordinate);

osgUtil::IntersectionVisitor iv(intersector.get());

iv.setTraversalMask(~0x1);

io_viewer.getCamera()->accept(iv);

 osgUtil::LineSegmentIntersector::Intersections intersections = 
intersector->getIntersections();

for (osgUtil::LineSegmentIntersector::Intersections::const_iterator i = 
intersections.begin();
i != intersections.end(); ++i)
{
if (nodePath.back()->getName() == "xxx")
{

osg::Vec3 lcsIntersectPoint = i->getLocalIntersectPoint();
float x = lcsIntersectPoint.x()
float y = lcsIntersectPoint.y();
returnValue = true;
break;
}
}



I draw a point at the coordinates i get in the end

Thank you!

Cheers,
Jochen

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74102#74102




Attachments: 
http://forum.openscenegraph.org//files/capture_252.png


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

Re: [osg-users] Model flickering on osgViewer

[L. Voerman]

This looks like a driver bug, an reminds me of a problem in the nvidia
driver having problems
with display lists combined with depth_clamp.
the osgviewer doesn't do the depthclamp, but the display lists might be a
problem here.
can you try:
set OSG_OPTIMIZER=INDEX_MESH
osgviewer cow.osg

Laurens.

On Thu, Jun 21, 2018 at 12:02 PM Eran Cohen  wrote:

> Hi,
>
> I compiled OpenSceneGraph 3.6.1 on a recently formatted Windows 10 laptop
> with up-to-date drivers.
> When I tried to run osgViewer with cow.osg, the model and screen started
> to 'flicker':
> [Image: https://preview.ibb.co/dbVWFT/photo.jpg ] (https://ibb.co/jeAnpo)
>
> but interestingly, when I took a screenshot, everything looked alright:
> [Image: https://preview.ibb.co/ic4u28/screenshot.jpg ] (
> https://ibb.co/e9ju28)
>
> Previously, the laptop was running Linux and this problem didn't happen.
> Does anyone have an idea why this is happening?
>
> Thanks,
> Eran
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74097#74097
>
>
>
>
>
> ___
> 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] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Tim Moore]

Hi Robert,

On Thu, Jun 21, 2018 at 9:35 AM, Robert Osfield 
wrote:

> Hi Tim,
>
> On Thu, 21 Jun 2018 at 08:25, Tim Moore  wrote:
>
>> Before you move on, the big advantage of std::shared_ptr over intrusive
>> reference counting is that support for weak pointers is rock solid. In the
>> intrusive model, you can't implement thread-safe weak pointers without an
>> auxiliary data structure, which complicates the implementation a lot. I
>> know that one historic OSG performance win for  osg::ref_ptr  was the
>> ability to not do the reference counting if it isn't needed, but with
>> atomic increment / decrement implemented everywhere, do you think there is
>> really much performance advantage for intrusive counting? Also,
>> std::make_shared<>() allocates the shared_ptr control block in the same
>> memory allocation as the shared object, so there need not be a memory
>> fragmentation hit for using shared_ptr.
>>
>>>
> The big advantage of intrusive reference counting is that the ref_ptr<>
> holds a pointer to the actual object that you want to access, it's a single
> jump. shared_ptr<> is literary a pointer to a shared pointer (which is a
> reference counted object) to a the actual object that you want to access,
> it's two pointers, two objects vs one pointer and one object.  Scene graphs
> are predominately memory bandwidth limited so this extra level of
> indirection is not even close to as efficient as intrusive reference
> counting.  The only advantage that shared_ptr<> has is that it works with
> any type, but with a scene graph the types are mostly all under our control
> there is no cost in complexity of having intrusive reference counting, just
> stick it into the base class that most classes use anyway and your job is
> done.
>
> This is not the way shared_ptr is implemented, at least in gcc. The shared
pointer contains a pointer to the object as well as to the control block.
You could argue that this makes a shared_ptr twice the size of an
osg::ref_ptr, but I really can't speculate on the overall effect on memory
usage.

> So... as my aim where possible is to make the VulkanSceneGraph more
> efficient than the OpenSceneGraph I can't just put chains around my ankles
> by adopting shared_ptr<>, instead I will acknowledge where the
> OpenSceneGraph already does something well and following this approach,
> albeit in a modern C++ way.
>
> For the thread safe observer_ptr<> you do need a separate auxiliary
> object, just like the OSG, so in my prototyping this is already what I have
> done.  I already have an vsg::Auxiliary object that is created when
> required, this Auxiliary object is for more than just supporting
> observer_ptr<> though, it also stores optional extra user data.  Doing this
> shrinks the base vsg::Object/Node classes and improves memory utilization,
> providing a measurable gain in construction, destruction and traversal of
> the scene graph over what can be done with the OSG.
>
What's the measured gain?

>
> When adopting new features of C++ you have to understand what is happening
> under the hood, for software that is performance critical like a scene
> graph you have to take the time to make sure
>
Agreed :)

> there aren't hidden performance costs are, if there is a cost then you
> have to be really sure that this cost is worth the value it provides.
> shared_ptr<>/weak_ptr<> don't cut it for the core scene graph.  There are
> plenty of other modern C++ features that are really neat and just make life
> easier without a cost, you'll see this sprinkled everywhere in the
> VulkanSceneGraph.
>
>
> Of course I trust your judgement, but I struggled mightily with weak
pointer thread safety back in the day and am happy to be able to make it
someone else's problem now. I am very happy that VulkanSceneGraph is coming
on the scene!

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

Re: [osg-users] LineSegmentIntersector doesn't give accurate Coordinates

[Robert Osfield]

Hi Jochen,

There is too many unknowns about what you are doing for us to be provide
any specific advice as to what is going wrong.

It could be that your are passing in the mouse coords incorrectly.  It
could be that you are interpreting the intersections coordinates
incorrectly.  It could be that you are inserting your visual markers
incorrectly.  It could be some other random thing that you are doing wrong.

As when doing know anything specific about your code there is nothing we
can do to help at this point.  You best next step would be to post some of
the code you are using to set up the intersection, to place your visual
markers and a screen shot of what is happening.

Cheers,
Robert.

On Thu, 21 Jun 2018 at 11:44, Jochen Schwitzer <
fasoldma63...@th-nuernberg.de> wrote:

> Hi,
>
> I am trying to get the local coordinates of my mouse in a 2D scene, when
> the mouse is clicked.
>
> I draw a transparent terrain and use the LineSegmentIntersector with the
> Mouse Coordinates to get the LocalIntersectionPoint and draw this point
> then.
>
> However, when I click, the point is always at some place else. Always
> relative to the mouse position but the distance varies when I zoom in or
> out.
>
> Can anybody help me? What am I missing?
>
> Thank you!
>
> Cheers,
> Jochen
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74098#74098
>
>
>
>
>
> ___
> 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] Model flickering on osgViewer

[Eran Cohen]

Hi,

I compiled OpenSceneGraph 3.6.1 on a recently formatted Windows 10 laptop with 
up-to-date drivers. 
When I tried to run osgViewer with cow.osg, the model and screen started to 
'flicker':
[Image: https://preview.ibb.co/dbVWFT/photo.jpg ] (https://ibb.co/jeAnpo)

but interestingly, when I took a screenshot, everything looked alright:
[Image: https://preview.ibb.co/ic4u28/screenshot.jpg ] (https://ibb.co/e9ju28)

Previously, the laptop was running Linux and this problem didn't happen.
Does anyone have an idea why this is happening?

Thanks,
Eran

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74097#74097





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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Tim,

On Thu, 21 Jun 2018 at 08:25, Tim Moore  wrote:

> Before you move on, the big advantage of std::shared_ptr over intrusive
> reference counting is that support for weak pointers is rock solid. In the
> intrusive model, you can't implement thread-safe weak pointers without an
> auxiliary data structure, which complicates the implementation a lot. I
> know that one historic OSG performance win for  osg::ref_ptr  was the
> ability to not do the reference counting if it isn't needed, but with
> atomic increment / decrement implemented everywhere, do you think there is
> really much performance advantage for intrusive counting? Also,
> std::make_shared<>() allocates the shared_ptr control block in the same
> memory allocation as the shared object, so there need not be a memory
> fragmentation hit for using shared_ptr.
>
>>
The big advantage of intrusive reference counting is that the ref_ptr<>
holds a pointer to the actual object that you want to access, it's a single
jump. shared_ptr<> is literary a pointer to a shared pointer (which is a
reference counted object) to a the actual object that you want to access,
it's two pointers, two objects vs one pointer and one object.  Scene graphs
are predominately memory bandwidth limited so this extra level of
indirection is not even close to as efficient as intrusive reference
counting.  The only advantage that shared_ptr<> has is that it works with
any type, but with a scene graph the types are mostly all under our control
there is no cost in complexity of having intrusive reference counting, just
stick it into the base class that most classes use anyway and your job is
done.

So... as my aim where possible is to make the VulkanSceneGraph more
efficient than the OpenSceneGraph I can't just put chains around my ankles
by adopting shared_ptr<>, instead I will acknowledge where the
OpenSceneGraph already does something well and following this approach,
albeit in a modern C++ way.

For the thread safe observer_ptr<> you do need a separate auxiliary object,
just like the OSG, so in my prototyping this is already what I have done.
I already have an vsg::Auxiliary object that is created when required, this
Auxiliary object is for more than just supporting observer_ptr<> though, it
also stores optional extra user data.  Doing this shrinks the base
vsg::Object/Node classes and improves memory utilization, providing a
measurable gain in construction, destruction and traversal of the scene
graph over what can be done with the OSG.

When adopting new features of C++ you have to understand what is happening
under the hood, for software that is performance critical like a scene
graph you have to take the time to make sure there aren't hidden
performance costs are, if there is a cost then you have to be really sure
that this cost is worth the value it provides.  shared_ptr<>/weak_ptr<>
don't cut it for the core scene graph.  There are plenty of other modern
C++ features that are really neat and just make life easier without a cost,
you'll see this sprinkled everywhere in the VulkanSceneGraph.

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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Tim Moore]

On Wed, Jun 20, 2018 at 8:14 AM, Robert Osfield 
wrote:

> Hi Scott,
>
> On Wed, 20 Jun 2018 at 08:09, Scott Bailey 
> wrote:
> > Wow is this ever good news!  I'm glad to see OSG will move into the
> future, albeit as VSG.  I'm especially excited to see modern c++ targeted.
> Personally, my preference is for c++14 if only for std::make_unique<>(),
> but I'll take c++11 any day!
>
> I guess there is chance I'll use std::unique_ptr<> and associated
> std::make_unique<>() at some point.  The scene graph itself will be
> managed using intrusive reference counting just like the OSG does for
> performance reasons, so I've prototyped equivalents of osg::ref_ptr<>
> and osg::Referenced for this purpose.  I guess one could also write a
> vsg::make_ref<> equivalent to std::make_unique<> if one so desired.
>
> Before you move on, the big advantage of std::shared_ptr over intrusive
reference counting is that support for weak pointers is rock solid. In the
intrusive model, you can't implement thread-safe weak pointers without an
auxiliary data structure, which complicates the implementation a lot. I
know that one historic OSG performance win for  osg::ref_ptr  was the
ability to not do the reference counting if it isn't needed, but with
atomic increment / decrement implemented everywhere, do you think there is
really much performance advantage for intrusive counting? Also,
std::make_shared<>() allocates the shared_ptr control block in the same
memory allocation as the shared object, so there need not be a memory
fragmentation hit for using shared_ptr.

Tim

> For now I'm wider design issues, doing experiments with more modern
> C++ along the way to see what is possible.  My general guide is that
> modern C++ features deployed needs to make the code easier to read and
> maintain than not using it, or provide significant flexibility/power
> that justifies any possible complexities in following the code.  So
> far so good on this count - I've been able to make the VSG equivalents
> of OSG much simpler thanks to modern C++ features.
>
> I won't make any decision on C++11 vs 14 vs 17 until the end of
> Exploration Phase.  If we can do everything we'll need with just C++11
> and there are few features of 14 and 17 that offer significant
> benefits then I'll likely just stick with C++11 for better backwards
> compatibility to older compilers.  The backwards compatibility with
> older compilers isn't a priority though, just something worth
> maintaining if it comes at no cost to the integrity/quality of the
> scene graph.
>
> I have to admit, I *really* like working with modern C++, looking back
> to some OSG code is bit painful now.  This isn't just C++ features
> though, my skills as programmer have slowly advanced over the years so
> now can spot better ways of solving problems.  Once VSG is established
> there may be a few areas of the OSG that could be updated to do
> similar things to what the VSG will do, though backwards compatibility
> for the OSG is crucial - it'll be a case of asking the question what
> can make OSG users lives better without risking breaking things.
>
> These possibilities are all a way off yet.  Through to the end of
> August I'll be just learning, thinking, experimenting with C++, Vulkan
> and ideas for improving scene graphs, and also getting OSG-3.6.2 out
> the door :-)
>
> Robert.
>
>
> >
> > If you haven't already seen it, check out the Magnum Graphics Engine.
> It's the only example I've found of anything close to a scene graph with a
> modern c++ interface.
> >
> > Best luck and Thanks!
> > SB
> > [/url]
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=74083#74083
> >
> >
> >
> >
> >
> > ___
> > 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