Hi Pawel,
On Thu, 9 Aug 2018 at 17:59, Paweł Księżopolski
wrote:
> If you are still in sponge mode - I just released new version of my Vulkan
> renderer, where you can find few articles linked from README.md.
>
> These articles describe some of the important aspects of my renderer
>
Hi Robert,
If you are still in sponge mode - I just released new version of my Vulkan
renderer, where you can find few articles linked from README.md.
These articles describe some of the important aspects of my renderer
architecture, that you may find inspiring, interesting or just simply
Hi. I think you should post this question in a new thread.
On 4 August 2018 at 13:33, Andrew Lowe wrote:
> On 02/06/18 01:22, Robert Osfield wrote:
>> Hi All,
>>
>> I am delighted to say that today I began work on VulkanSceneGraph,
>
> [snip]
>
>>
>> I also will be looking into what features of
On 02/06/18 01:22, Robert Osfield wrote:
> Hi All,
>
> I am delighted to say that today I began work on VulkanSceneGraph,
[snip]
>
> I also will be looking into what features of modern C++ can bring to
> the table to make our lives as graphics developers easier and more
> productive, C++11, 14
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
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
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
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
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
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
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
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
Robert,
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!
If you haven't already seen it, check
Hi Thomas,
On Sat, 9 Jun 2018 at 03:09, Thomas Hogarth wrote:
> I'd by up for making a small unit test application framework. This is also a
> problem for osg examples at the mo. They only run in console/desktop
> environments.
>
> I could develop a simple DemoBase class or whatever, examples
Add my two cents
I'd by up for making a small unit test application framework. This is also a
problem for osg examples at the mo. They only run in console/desktop
environments.
I could develop a simple DemoBase class or whatever, examples and Unit tests
inherit from that and then for each
Hi Chris,
On Thu, 7 Jun 2018 at 22:19, Chris Hanson wrote:
> I was mostly suggesting POCO in terms of all of the support code that it
> provides for the parts outside the core scenegraph. But I understand that
> that's not what you're focusing on right now.
One thing I feel is worth doing is
I was mostly suggesting POCO in terms of all of the support code that it
provides for the parts outside the core scenegraph. But I understand that
that's not what you're focusing on right now.
On Thu, Jun 7, 2018 at 11:55 AM Robert Osfield
wrote:
> Hi Chris,
> On Thu, 7 Jun 2018 at 17:24, Chris
Hi Chris,
On Thu, 7 Jun 2018 at 18:54, Robert Osfield wrote:
> > Jeremy Moles' Heirograph scenegraph (GL3+, GLES2+ and prototype Vulkan
> > support) used GLM ( https://glm.g-truc.net/0.9.9/index.html ) instead,
> > because the syntax of the math library is exactly the same as GLSL's. Not
> >
Hi Chris,
On Thu, 7 Jun 2018 at 17:24, Chris Hanson wrote:
> I would like to throw out the concept of using something like Conan.io (
> https://conan.io/ ) to assist with 3rdparty package management.
For the current phase of work I don't plan to look at package
management, my current focus is
I'm going to avoid discussing header extensions, because it's a dead dog. I
will say, that more tools and processes than just VS rely on file
extensions.
I would like to throw out the concept of using something like Conan.io (
https://conan.io/ ) to assist with 3rdparty package management.
As we
Hi Björn,
I've heard all these points before, didn't find them convincing in the
early days of the OSG and still don't. Given the same set of facts I
simply have a different opinion on how we should weight them.
Repeating points 100 times won't magically tip the balance, it's just
makes me fed up
robertosfield wrote:
>
> For the OpenSceneGraph, the VulkanSceneGraph I aspire to be a Stardard
> C++ library for real-time graphics.
In my mind (and I also think the general convention is that) the extensionless
headers are reserved for libraries accepted into the STL by the ISO committee.
On Thu, 7 Jun 2018 at 11:28, michael kapelko wrote:
> Since we're talking about standard proposals now, here are some I would want:
No we aren't, I didn't start this thread to debate with the community
the pros and cons of every decisions. I made the original an
announcement that project is
On Thu, 7 Jun 2018 at 10:32, Björn Blissing wrote:
> The ISO cpp guidelines recommend using .h for headers and .cpp for source:
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-file-suffix
So use .h unless you want to maintain consistency with existing
Since we're talking about standard proposals now, here are some I would want:
1. Provide an option of single header and source file per each module:
vsg.h/cpp, vsgViewer.h/cpp, vsgUtil.h/cpp, etc.
This would greatly simplify referencing VSG across platforms because
CMake has issues under Android
robertosfield wrote:
>
>
> > And maybe this time we will get header files with the .h extension. ;)
> >
>
> Maybe, no decisions made yet, but I'm also not polling for opinions,
> the VulkanSceneGraph isn't a design by committee.
>
> My initial code experiments have .hpp but frankly it's ugly
On Thu, 7 Jun 2018 at 08:49, Björn Blissing wrote:
> 1. Use modern CMake - this will make the project much easier to use.
Modern CMake and xmake are on the short list.
> 2. Minimize external dependencies - Preferably the project should be able to
> be used without any external dependencies
Hi Robert,
Very exciting news!
I do not have any strong opinions on the Vulcan parts. But I do have some
wishes since this project is starting from scratch:
1. Use modern CMake - this will make the project much easier to use.
2. Minimize external dependencies - Preferably the project should
On 5 June 2018 at 21:42, Ravi Mathur wrote:
> Nevertheless, supporting MacOS alongside Windows & Linux is a necessity in
> my field (aerospace). It looks like Vulkan will be available on OSX, even if
> it's without Apple's official support. Once VulkanSceneGraph gets going,
> I'll do my bit to
I've been using Macs and developing on MacOS for over 25 years now, but
still I gotta say I completely understand your frustration Robert. My past
two computers have been Windows laptops, which is also the first time I've
bought non-Mac hardware, mainly because Apple doesn't seem to care about VR
On 5 June 2018 at 19:51, Andrew Cunningham wrote:
> Great news and very timely given Apple’s just announced decision to deprecate
> OpenGL
Apple are behaving like complete * that don't give a shit about developers.
It's time users stopped putting up with this crap and just dumped
Apple
Hi Sam,
On 5 June 2018 at 17:30, sam wrote:
> Regarding SceneGraphTestBed are we looking to have a library to help
> facilitate testing? What is the current vision for the test repository.
I am open to suggestions and support. My motivation is that both the
OpenSceneGraph and VulkanSceneGraph
Great news and very timely given Apple’s just announced decision to deprecate
OpenGL
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73979#73979
___
osg-users mailing list
Hi all
MoltenVk is a Vulkan implementation, so not a great constraint, only some cmake
code and macros to prevent incompatibilities are to be forseen:
https://www.moltengl.com/docs/readme/moltenvk-0.13.0-readme-user-guide.html#install
Concerning Android Vulkan support begins with API 22
Hi Robert,
Regarding SceneGraphTestBed are we looking to have a library to help
facilitate testing? What is the current vision for the test repository.
Thanks, Sam
On Tue, Jun 5, 2018 at 1:35 AM Robert Osfield
wrote:
> Hi Julien,
>
> On 4 June 2018 at 18:03, Julien Valentin
> wrote:
> > Glad
Hi Julien,
On 4 June 2018 at 18:03, Julien Valentin wrote:
> Glad to hear vsg is on the grill. As Remo wrote, MoltenVk should be taken
> into consideration in the design of VSG for the Mac/IOS compatibility.
I haven't investigated MoltenVk yet, are there gotcha's involved in
supporting it?
>
Hi all
Thanks pawel_xx for the resources, some are very interesting
I forgot to mention Anvil the AMD vulkan c++ wrapping
https://github.com/GPUOpen-LibrariesAndSDKs/Anvil
Don't know what it worse...
Cheers
pawel_xx wrote:
> > Thanks for the link to your pumex library.
> > I've downloaded it
Hi Pawel,
Thanks for the links. I have the book already and already download
some of the resources, some new ones too so very helpful.
Earlier today I downloaded and played a bit with your pumex examples.
Design wise I can probably work out most of it from the implementation
so no need to write
> Thanks for the link to your pumex library.
> I've downloaded it and run the examples.
I encourage you to take a look at the sourcecode
of the examples - I made it similar to OSG code.
> If there are any resources that you've found
> really helpful let me know.
Vulkan specification is the
Hi all
Glad to hear vsg is on the grill. As Remo wrote, MoltenVk should be taken into
consideration in the design of VSG for the Mac/IOS compatibility.
@Robert classic Vulkan resources I read (if you don't already have them):
-Vulkan Programming Guide (Graham Sellers)
-per feature examples:
Hi Robert
MacOSX has no official support of Vulkan :(
But Khronos has a Vulkan to Metal runtime:
https://github.com/KhronosGroup/MoltenVK
Cheers,
Remo
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73957#73957
HI Michael,
On 4 June 2018 at 13:55, michael kapelko wrote:
> 1. Target C++20: by the end of 2030, when (supposedly) all new
> graphics software uses Vulkan, C++20 will be old enough
;-)
At this point in time I want both the OSG and VSG to be forwards
compatible with C++17, so if users use it
Hi. Great news!
1. Target C++20: by the end of 2030, when (supposedly) all new
graphics software uses Vulkan, C++20 will be old enough
2. My personal concern is the ability to run VSG on linux, windows,
mac, ios, android, and web browsers, so I volunteer to help in testing
closs-platformness of
Hi Robert
I am pleased to hear that you decided to move into the Vulkan development.
Creating VirtualSceneGraph may shape graphics development for
many years to come.
It may have great impact on open source projects, because in my opinion
the current state of Vulkan open source development is
Hi All,
I am delighted to say that today I began work on VulkanSceneGraph, an
all new scene graph that builds upon Vulkan and modern C++. This new
project can be thought of a new family member, the child of
OpenSceneGraph project. As it's a family member I've created the
project repository
45 matches
Mail list logo
